From isms-bounces@ietf.org  Tue Apr  5 10:34:30 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25789;
	Tue, 5 Apr 2005 10:34:30 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIpGd-0003ee-4Y; Tue, 05 Apr 2005 10:42:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIp7U-0004tR-Bj; Tue, 05 Apr 2005 10:33:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIp7T-0004rt-9o
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 10:33:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25659
	for <isms@ietf.org>; Tue, 5 Apr 2005 10:33:27 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIpFc-0003Zn-7X
	for isms@ietf.org; Tue, 05 Apr 2005 10:41:56 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j35EX9I16673
	for <isms@ietf.org>; Tue, 5 Apr 2005 10:33:09 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j35EX8e14640
	for <isms@ietf.org>; Tue, 5 Apr 2005 10:33:08 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RF1T2>; Tue, 5 Apr 2005 10:33:08 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402FA69E3@zcarhxm2.corp.nortel.com>
From: "Sharon Chisholm" <schishol@nortel.com>
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 5 Apr 2005 10:32:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

hi

Out of band keying is what is required.

Sharon 

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Ken Hornstein
Sent: Friday, March 18, 2005 6:40 PM
To: isms@ietf.org
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
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 12:10:24 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04472;
	Tue, 5 Apr 2005 12:10:24 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIqlS-0007DZ-ME; Tue, 05 Apr 2005 12:18:55 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIqWV-0003tc-Pm; Tue, 05 Apr 2005 12:03:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqWT-0003tD-Rh
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 12:03:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03845
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:03:22 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIqee-0006x1-GN
	for isms@ietf.org; Tue, 05 Apr 2005 12:11:53 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j35G3FPl021340; 
	Tue, 5 Apr 2005 16:03:15 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j35G2hUV009484; 
	Tue, 5 Apr 2005 16:03:15 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005040509031509924 ; Tue, 05 Apr 2005 09:03:15 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 5 Apr 2005 09:03:15 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 5 Apr 2005 09:03:14 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 5 Apr 2005 12:03:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 5 Apr 2005 12:02:46 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929EDE0CD@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcU57LR6+4RCUkB7SvmYxTt7M52uIQAC9tTw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sharon Chisholm" <schishol@nortel.com>, <isms@ietf.org>
X-OriginalArrivalTime: 05 Apr 2005 16:03:04.0257 (UTC)
	FILETIME=[F310E310:01C539F8]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: quoted-printable

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.=20

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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Sharon Chisholm
Sent: Tuesday, April 05, 2005 10:33 AM
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

hi

Out of band keying is what is required.

Sharon=20

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On
Behalf Of Ken Hornstein
Sent: Friday, March 18, 2005 6:40 PM
To: isms@ietf.org
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
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 12:29:20 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06473;
	Tue, 5 Apr 2005 12:29:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIr3m-00086F-H2; Tue, 05 Apr 2005 12:37:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIqtZ-0001sq-LC; Tue, 05 Apr 2005 12:27:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqtX-0001sc-PV
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 12:27:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06258
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:27:06 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIr1b-0007zc-8T
	for isms@ietf.org; Tue, 05 Apr 2005 12:35:37 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j35GQhp12744
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:26:43 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j35GQfl09172
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:26:42 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RF2R4>; Tue, 5 Apr 2005 12:26:42 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402FA6BA9@zcarhxm2.corp.nortel.com>
From: "Sharon Chisholm" <schishol@nortel.com>
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 5 Apr 2005 12:26:26 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290

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:uri.blumenthal@intel.com] 
Sent: Tuesday, April 05, 2005 12:03 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]; isms@ietf.org
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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Sharon Chisholm
Sent: Tuesday, April 05, 2005 10:33 AM
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

hi

Out of band keying is what is required.

Sharon 

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On
Behalf Of Ken Hornstein
Sent: Friday, March 18, 2005 6:40 PM
To: isms@ietf.org
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
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 12:32:08 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06755;
	Tue, 5 Apr 2005 12:32:08 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIr6U-0008De-4Q; Tue, 05 Apr 2005 12:40:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIqxp-0002wO-QS; Tue, 05 Apr 2005 12:31:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqxp-0002wG-6v
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 12:31:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06704
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:31:38 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIr5z-0008CM-GH
	for isms@ietf.org; Tue, 05 Apr 2005 12:40:08 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50) id 1DIqxm-0003i8-7m
	for isms@ietf.org; Tue, 05 Apr 2005 12:31:38 -0400
Date: Tue, 5 Apr 2005 12:32:33 -0400
From: Robert Story <rstory@freesnmp.com>
To: isms@ietf.org
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050405123233.184aada5@aud>
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929EDE0CD@pysmsx401.amr.corp.intel.com>
References: <3DEC199BD7489643817ECA151F7C5929EDE0CD@pysmsx401.amr.corp.intel.com>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit

On Tue, 5 Apr 2005 12:02:46 -0400 Blumenthal, wrote:
BU> Another problem is how to integrate it smoothly, and yet another one -
BU> [artificially] created need to maintain and synchronize two protocols
BU> and implementations.
BU> 
BU> Summary: I'm a strong proponent of in-band keying.

I agree with Uri here, with encapsulation keying being my second choice.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 12:36:41 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07034;
	Tue, 5 Apr 2005 12:36:41 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIrAt-0008Is-Mk; Tue, 05 Apr 2005 12:45:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIr0n-0003h4-JB; Tue, 05 Apr 2005 12:34:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIr0m-0003gw-32
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 12:34:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06953
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:34:40 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIr8w-0008GW-Sf
	for isms@ietf.org; Tue, 05 Apr 2005 12:43:11 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j35GYYac013956; 
	Tue, 5 Apr 2005 16:34:34 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j35GYFUL004537; 
	Tue, 5 Apr 2005 16:34:34 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005040509343205227 ; Tue, 05 Apr 2005 09:34:32 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 5 Apr 2005 09:34:31 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 5 Apr 2005 09:34:31 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 5 Apr 2005 12:34:30 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 5 Apr 2005 12:34:12 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929EDE114@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcU5/I/QBHn5yCtjTxq8ivz+66r3vAAAFNaQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sharon Chisholm" <schishol@nortel.com>, <isms@ietf.org>
X-OriginalArrivalTime: 05 Apr 2005 16:34:30.0042 (UTC)
	FILETIME=[5714D7A0:01C539FD]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Content-Transfer-Encoding: quoted-printable

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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Sharon Chisholm
Sent: Tuesday, April 05, 2005 12:26 PM
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

hi

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

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:uri.blumenthal@intel.com]=20
Sent: Tuesday, April 05, 2005 12:03 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]; isms@ietf.org
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.=20

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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Sharon Chisholm
Sent: Tuesday, April 05, 2005 10:33 AM
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

hi

Out of band keying is what is required.

Sharon=20

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On
Behalf Of Ken Hornstein
Sent: Friday, March 18, 2005 6:40 PM
To: isms@ietf.org
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
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 12:38:42 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07233;
	Tue, 5 Apr 2005 12:38:42 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIrCq-0008O5-RY; Tue, 05 Apr 2005 12:47:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIr3L-00043o-32; Tue, 05 Apr 2005 12:37:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIr3J-00043P-SI
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 12:37:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07093
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:37:18 -0400 (EDT)
Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIrBT-0008JE-W7
	for isms@ietf.org; Tue, 05 Apr 2005 12:45:49 -0400
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com
	[172.29.225.253])
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id j35Gaw2S018002;
	Tue, 5 Apr 2005 09:36:58 -0700 (PDT)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service
	(5.5.2657.72) id <H0PA6LVM>; Tue, 5 Apr 2005 09:36:58 -0700
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7B29@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Robert Story'" <rstory@freesnmp.com>, isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 5 Apr 2005 09:36:58 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

Hi,

I agree with Uri and Robert here.  I think Sharon is being
naive to expect that out-of-band keying won't actually be
very hard - since the keys MUST be of session duration to
have any reasonable degree of security.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On
Behalf Of Robert Story
Sent: Tuesday, April 05, 2005 12:33 PM
To: isms@ietf.org
Subject: Re: [Isms] Discussion: Architecture direction for ISMS


On Tue, 5 Apr 2005 12:02:46 -0400 Blumenthal, wrote:
BU> Another problem is how to integrate it smoothly, and yet another one -
BU> [artificially] created need to maintain and synchronize two protocols
BU> and implementations.
BU> 
BU> Summary: I'm a strong proponent of in-band keying.

I agree with Uri here, with encapsulation keying being my second choice.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 12:51:37 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08059;
	Tue, 5 Apr 2005 12:51:37 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIrPM-0000LO-Dw; Tue, 05 Apr 2005 13:00:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIr8I-0004VX-Mk; Tue, 05 Apr 2005 12:42:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIr8I-0004VO-1b
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 12:42:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07412
	for <isms@ietf.org>; Tue, 5 Apr 2005 12:42:26 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIrGS-00005H-Aw
	for isms@ietf.org; Tue, 05 Apr 2005 12:50:57 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 4270511D8F7; Tue,  5 Apr 2005 09:42:22 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "McDonald, Ira" <imcdonald@sharplabs.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Organization: Sparta
References: <CFEE79A465B35C4385389BA5866BEDF00C7B29@mailsrvnt02.enet.sharplabs.com>
Date: Tue, 05 Apr 2005 09:42:21 -0700
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7B29@mailsrvnt02.enet.sharplabs.com>
	(Ira McDonald's message of "Tue, 5 Apr 2005 09:36:58 -0700")
Message-ID: <sdvf712n0y.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

>>>>> On Tue, 5 Apr 2005 09:36:58 -0700 , "McDonald, Ira" <imcdonald@sharplabs.com> said:

Ira> I agree with Uri and Robert here.

As do I.  Specifically, I think Robert's ordering of requirements
matches mine.  In-band first, and encapsulated being a second choice.
As I've mentioned in multiple other messages, there are a large number
of issues with out-of-band keying that makes implementation
difficult.  I suspect Sharon must not agree with any of those other points?

-- 
Wes Hardaker
Sparta

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 14:03:34 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13371;
	Tue, 5 Apr 2005 14:03:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIsWx-0002oB-3e; Tue, 05 Apr 2005 14:12:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIsMm-0008VH-Jx; Tue, 05 Apr 2005 14:01:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIsMl-0008V5-BK
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 14:01:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13191
	for <isms@ietf.org>; Tue, 5 Apr 2005 14:01:29 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIsUw-0002l4-8k
	for isms@ietf.org; Tue, 05 Apr 2005 14:09:59 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j35I1DW19669
	for <isms@ietf.org>; Tue, 5 Apr 2005 14:01:13 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j35I14R10547
	for <isms@ietf.org>; Tue, 5 Apr 2005 14:01:04 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RFLN4>; Tue, 5 Apr 2005 14:01:05 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402FA6CEA@zcarhxm2.corp.nortel.com>
From: "Sharon Chisholm" <schishol@nortel.com>
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 5 Apr 2005 14:00:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a


<Wes>

As do I.  Specifically, I think Robert's ordering of requirements matches
mine.  In-band first, and encapsulated being a second choice. As I've
mentioned in multiple other messages, there are a large number of issues
with out-of-band keying that makes implementation difficult.  I suspect
Sharon must not agree with any of those other points?
</Wes>

No, not really. After our discussion in Minneapolis where you mentioned the
fact that you felt separate key management would be impossible to implement
in net-snmp, I went back and talked to some more SNMPv3 implementers to get
their view of implementing eUSM and although they observed there were some
missing elements of procedure, they saw nothing that they felt would cause
implementation problems.

I'm a big fan of modular architectures. It allows you to add functionality
as you need it and to ensures a good return in investment when looking to
add new features. Yes, there are points where having too many separate
modules to worry about starts to cost more than it saves and then you look
at combining things together to get some improvements. I don't think we are
there in this particular case.

Sharon

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 14:53:13 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18163;
	Tue, 5 Apr 2005 14:53:13 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DItJ2-0004fx-6F; Tue, 05 Apr 2005 15:01:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIt9H-0007ja-NM; Tue, 05 Apr 2005 14:51:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIt9G-0007jV-4r
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 14:51:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18038
	for <isms@ietf.org>; Tue, 5 Apr 2005 14:51:36 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DItHR-0004aF-GI
	for isms@ietf.org; Tue, 05 Apr 2005 15:00:06 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 1F29B11D8F7; Tue,  5 Apr 2005 11:51:30 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "Sharon Chisholm" <schishol@nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Organization: Sparta
References: <713043CE8B8E1348AF3C546DBE02C1B402FA6CEA@zcarhxm2.corp.nortel.com>
Date: Tue, 05 Apr 2005 11:51:29 -0700
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B402FA6CEA@zcarhxm2.corp.nortel.com>
	(Sharon Chisholm's message of "Tue, 5 Apr 2005 14:00:50 -0400")
Message-ID: <sdacodys3y.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

>>>>> On Tue, 5 Apr 2005 14:00:50 -0400 , "Sharon Chisholm" <schishol@nortel.com> said:

Sharon> No, not really. After our discussion in Minneapolis where you
Sharon> mentioned the fact that you felt separate key management would
Sharon> be impossible to implement in net-snmp, I went back and talked
Sharon> to some more SNMPv3 implementers to get their view of
Sharon> implementing eUSM and although they observed there were some
Sharon> missing elements of procedure, they saw nothing that they felt
Sharon> would cause implementation problems.

Well, I don't think I said "impossible".  I said it would be difficult
to keep it portable.  I would suspect that anyone implementing a
portable SNMPv3 stack will run into  similar problems.  When you need
to interface with another protocol server (EG, EAP per EUSM) then you
need to either:

1) create your SNMP stack library so that it offers generic keying
   APIs and let the vendor who is producing a box tie it together with
   whatever keying stack they're using.  This means each vendor does a
   lot of work.

2) create your SNMP stack library so that it personally tries to
   interface with all other known keying stack vendors.  This means
   that each SNMP stack vendor (M total, say) would have to support N
   keying stack vendors.  You could only support one keying stack
   vendor, for example, but that's breaking portability which most
   SNMP stack vendors offer now.

3) create your SNMP stack so it offered its own keying stack/service
   itself.  This of course runs into conflicts when any other service
   on a device also needs to open a keying service or if 2 SNMP
   vendors are both going to exist on the same device (something my
   users do all the time).  This is the least friendly solution.

4) standardize on an API to talk between the keying stack and the SNMP
   stack (which really means just standardize on a keying API probably).

I didn't say it's impossible, because clearly it is possible.  It's
just difficult, requires a lot of work and you loose portability in
the process if you don't cover all possible permutations.

There are also security issues with passing those keys around within a
device and ensuring that the right service receives the right key.
This isn't a bad thing, it's just a difficult thing and it just needs
to be implemented carefully.  In some architectures, having the keys
readable by every application isn't an issue because they don't run on
memory-protected operating systems.  I use the other extreme most of
the time where I'm very picky about which applications have access to
which data.


-- 
Wes Hardaker
Sparta

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 14:59:09 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18804;
	Tue, 5 Apr 2005 14:59:09 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DItOm-0004wS-1C; Tue, 05 Apr 2005 15:07:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DItEo-0000E3-ES; Tue, 05 Apr 2005 14:57:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DItEm-0000Dy-Gp
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 14:57:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18599
	for <isms@ietf.org>; Tue, 5 Apr 2005 14:57:18 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItMx-0004q7-TL
	for isms@ietf.org; Tue, 05 Apr 2005 15:05:49 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j35Iuro02533; Tue, 5 Apr 2005 14:56:53 -0400 (EDT)
Received: from nortelnetworks.com (wcary0w4.ca.nortel.com [47.129.148.152]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id FKG7L94P; Tue, 5 Apr 2005 14:56:54 -0400
Message-ID: <4252DF75.5090805@nortelnetworks.com>
Date: Tue, 05 Apr 2005 14:56:53 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Marcus Leech <mleech@nortel.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929EDE0CD@pysmsx401.amr.corp.intel.com>
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929EDE0CD@pysmsx401.amr.corp.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit



Blumenthal, Uri wrote:

>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. 
>
>  
>
Ok, so call me thick-as-a-brick, but I find *zero* references to 
"sessions" (or, consequently,
  their lifetimes) in RFC3414.  Granted, we *need* the notion of 
sessions, but I can't
  see why an external keying protocol necessarily precludes correct 
synchronization.

There are certainly schemes one could think of (perhaps involving 
functional overloading
  of existing protocol elements in USM/RFC3414) that would overlay a 
session concept, and
  continue to allow for a near-complete divorce between USM and its key 
management protocol.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 15:06:32 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19797;
	Tue, 5 Apr 2005 15:06:32 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DItVv-000599-By; Tue, 05 Apr 2005 15:15:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DItN6-0001Wt-IT; Tue, 05 Apr 2005 15:05:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DItN5-0001Wi-E2
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 15:05:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19669
	for <isms@ietf.org>; Tue, 5 Apr 2005 15:05:52 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItVG-00057p-3E
	for isms@ietf.org; Tue, 05 Apr 2005 15:14:23 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j35J5XR09518; Tue, 5 Apr 2005 15:05:33 -0400 (EDT)
Received: from nortelnetworks.com (wcary0w4.ca.nortel.com [47.129.148.152]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id FKG7L9WR; Tue, 5 Apr 2005 15:05:34 -0400
Message-ID: <4252E17D.8060104@nortelnetworks.com>
Date: Tue, 05 Apr 2005 15:05:33 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Marcus Leech <mleech@nortel.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wes Hardaker <hardaker@tislabs.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <713043CE8B8E1348AF3C546DBE02C1B402FA6CEA@zcarhxm2.corp.nortel.com>
	<sdacodys3y.fsf@wes.hardakers.net>
In-Reply-To: <sdacodys3y.fsf@wes.hardakers.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit



Wes Hardaker wrote:

>
>There are also security issues with passing those keys around within a
>device and ensuring that the right service receives the right key.
>This isn't a bad thing, it's just a difficult thing and it just needs
>to be implemented carefully.  In some architectures, having the keys
>readable by every application isn't an issue because they don't run on
>memory-protected operating systems.  I use the other extreme most of
>the time where I'm very picky about which applications have access to
>which data.
>  
>
Everything in security (or any other piece of software for that matter)
  "needs to be implemented carefully".  I don't view that as any kind of
  argument for/against any particular architecture.  The converse
  "with architecture A, you can be quite sloppy in your implementation, 
and it'll
   probably still be secure" hangs by a very thin thread indeed.

With the exception of some very-highly-specialized pieces of hardware,
  once a key is in memory, one can get at it, whether the operating system
  enforces inter-application access controls or not.  Clearly, there are
  "prudent practices" those of us in the security implementation 
business use,
  but we must be very clear that such practices merely offer a barrier 
of *inconvenience*,
  rather than absolute security.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 16:09:47 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08489;
	Tue, 5 Apr 2005 16:09:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIuV8-0002zt-6A; Tue, 05 Apr 2005 16:18:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DItgj-0003sk-TP; Tue, 05 Apr 2005 15:26:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DItgh-0003sa-DC
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 15:26:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22918
	for <isms@ietf.org>; Tue, 5 Apr 2005 15:26:09 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DItos-0005yH-Vb
	for isms@ietf.org; Tue, 05 Apr 2005 15:34:40 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 67B1711D8F7; Tue,  5 Apr 2005 12:26:04 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Marcus Leech <mleech@nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Organization: Sparta
References: <713043CE8B8E1348AF3C546DBE02C1B402FA6CEA@zcarhxm2.corp.nortel.com>
	<sdacodys3y.fsf@wes.hardakers.net>
	<4252E17D.8060104@nortelnetworks.com>
Date: Tue, 05 Apr 2005 12:26:03 -0700
In-Reply-To: <4252E17D.8060104@nortelnetworks.com> (Marcus Leech's message of
	"Tue, 05 Apr 2005 15:05:33 -0400")
Message-ID: <sdsm25vxdg.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

>>>>> On Tue, 05 Apr 2005 15:05:33 -0400, Marcus Leech <mleech@nortel.com> said:

Marcus> Everything in security (or any other piece of software for
Marcus> that matter) "needs to be implemented carefully".

Agreed.

Marcus> I don't view that as any kind of argument for/against any
Marcus> particular architecture.  The converse "with architecture A,
Marcus> you can be quite sloppy in your implementation, and it'll
Marcus> probably still be secure" hangs by a very thin thread indeed.

Never said otherwise.  When you have 1 keying service handing keys to
multiple other services which need those keys, it adds to system
complexity.  That's all I was saying and you seem to have taken a huge
leap to extrapolate what I was saying to proving that one architecture
is more secure than another.  I do consider some architectures to be
more complex than others, which does lead to implementation burdens
that may result in a greater number of places where mistakes can be
made.  It's often the case that if you implement any architecture
which has been proven to be secure perfectly you will never have
issues.  I agree.  I disagree that implementing all architectures
perfectly involve the same cost and complexity.

Marcus> With the exception of some very-highly-specialized pieces of
Marcus> hardware, once a key is in memory, one can get at it, whether
Marcus> the operating system enforces inter-application access
Marcus> controls or not.  Clearly, there are "prudent practices" those
Marcus> of us in the security implementation business use, but we must
Marcus> be very clear that such practices merely offer a barrier of
Marcus> *inconvenience*, rather than absolute security.

Agreed.  Security is always a sliding scale.  However, "trusted OSes"
that offer better protection than their counterparts are more secure
in most people's eyes because those "inconveniences" are difficult to
pass by easily.  Certainly specialized hardware is an even better
solution to the problem, assuming you can afford the cost.  But we
digress.


-- 
Wes Hardaker
Sparta

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr  5 16:10:18 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08652;
	Tue, 5 Apr 2005 16:10:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DIuVd-00032d-Uu; Tue, 05 Apr 2005 16:18:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DIu3U-0003oE-7P; Tue, 05 Apr 2005 15:49:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DIu3S-0003nw-O8
	for isms@megatron.ietf.org; Tue, 05 Apr 2005 15:49:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00303
	for <isms@ietf.org>; Tue, 5 Apr 2005 15:49:40 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIuBe-0008NK-D6
	for isms@ietf.org; Tue, 05 Apr 2005 15:58:11 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j35JnRsC006262; 
	Tue, 5 Apr 2005 12:49:27 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j35JmvKC031606;
	Tue, 5 Apr 2005 12:48:57 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j35Jmvbv031602; Tue, 5 Apr 2005 12:48:57 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Tue, 5 Apr 2005 12:48:57 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Sharon Chisholm <schishol@nortel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B402FA6CEA@zcarhxm2.corp.nortel.com>
Message-ID: <Pine.LNX.4.10.10504051237090.23419-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da

HI,

Lets set up a conference call to talk this through.

Wes knows the internals of NET-SNMP. I've been going through
the SNMP Research code. Hopefully we can get some other
developers with knowledge of other SNMP stacks together
to work this out.

And if any developers that are using the SNMP Research stack
want to talk to me about details, I'm open to setting up
a private conversation. Send me email. (I cannot talk
in detail about the code, since it is covered by a
non-disclosure agreement, unless the other person
is also covered by the non-disclosure agreement.)

I would certainly appreciate talking with the SNMP developers
at Nortel. Let me know a time and a place, and I'll
try to come visit for a day or two. Likewise, if anyone
else wants to have a developer to developer talk,
please contact me.

I've been doing some serious work on SNMPv3 for the last
few months, and have had many meetings with the developers
from the network management group, and with the security
developers. SNMPv3 USM is quite difficult to understand,
and email doesn't provide an effective medium for
communication. Packet dumps, working code, multiple
screens with the RFCs are tools that are needed to
make progress.

On Tue, 5 Apr 2005, Sharon Chisholm wrote:
> <Wes>
> 
> As do I.  Specifically, I think Robert's ordering of requirements matches
> mine.  In-band first, and encapsulated being a second choice. As I've
> mentioned in multiple other messages, there are a large number of issues
> with out-of-band keying that makes implementation difficult.  I suspect
> Sharon must not agree with any of those other points?
> </Wes>
> 
> No, not really. After our discussion in Minneapolis where you mentioned the
> fact that you felt separate key management would be impossible to implement
> in net-snmp, I went back and talked to some more SNMPv3 implementers to get
> their view of implementing eUSM and although they observed there were some
> missing elements of procedure, they saw nothing that they felt would cause
> implementation problems.
> 
> I'm a big fan of modular architectures. It allows you to add functionality
> as you need it and to ensures a good return in investment when looking to
> add new features. Yes, there are points where having too many separate
> modules to worry about starts to cost more than it saves and then you look
> at combining things together to get some improvements. I don't think we are
> there in this particular case.
> 
> Sharon

Regards,
/david t. perkins


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Sat Apr  9 05:17:25 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20750;
	Sat, 9 Apr 2005 05:17:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DKCEi-0005Yt-Pp; Sat, 09 Apr 2005 05:26:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DKC3v-0001OA-CZ; Sat, 09 Apr 2005 05:15:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DKC3t-0001O5-Lk
	for isms@megatron.ietf.org; Sat, 09 Apr 2005 05:15:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20683
	for <isms@ietf.org>; Sat, 9 Apr 2005 05:15:27 -0400 (EDT)
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKCCo-0005X5-IX
	for isms@ietf.org; Sat, 09 Apr 2005 05:24:43 -0400
Received: from dialin-145-254-215-158.arcor-ip.net
	(dialin-145-254-220-148.arcor-ip.net [145.254.220.148])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 482D21BAC4D
	for <isms@ietf.org>; Sat,  9 Apr 2005 11:15:15 +0200 (CEST)
Date: Sat, 09 Apr 2005 11:15:11 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: isms@ietf.org
Message-ID: <DDE9B8400F5C801B3D339E58@dialin-145-254-215-158.arcor-ip.net>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Subject: [Isms] minutes of our session in Minneapolis
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit

Dear all,

Please find the minutes of our session in Minneapolis at

    <ftp://ftp.netlab.nec.de/pub/isms/IETF62/0-isms-minutes-ietf62.txt>.

If you want to get more details about our discussions, you will find the
audio recording of the session at

    <ftp://ftp.netlab.nec.de/pub/isms/IETF62/ietf62-ch5-mon-eve.mp3>

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 10:18:59 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03274;
	Tue, 12 Apr 2005 10:18:59 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLMNr-00020n-Rt; Tue, 12 Apr 2005 10:28:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLMB6-0008BM-D0; Tue, 12 Apr 2005 10:15:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLMB5-00083Q-Gn
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 10:15:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02834
	for <isms@ietf.org>; Tue, 12 Apr 2005 10:15:10 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLMKB-0001ur-C3
	for isms@ietf.org; Tue, 12 Apr 2005 10:25:07 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3CEEoi28270
	for <isms@ietf.org>; Tue, 12 Apr 2005 10:14:50 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3CEEpJ27170
	for <isms@ietf.org>; Tue, 12 Apr 2005 10:14:51 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3R2SGN>; Tue, 12 Apr 2005 10:14:48 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4030B8926@zcarhxm2.corp.nortel.com>
From: "Sharon Chisholm" <schishol@nortel.com>
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 12 Apr 2005 10:14:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

hi

Somehow using a code inspection to determine the correct architecture seems
very wrong to me.

Sharon

-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com] 
Sent: Tuesday, April 05, 2005 3:49 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS


HI,

Lets set up a conference call to talk this through.

Wes knows the internals of NET-SNMP. I've been going through the SNMP
Research code. Hopefully we can get some other developers with knowledge of
other SNMP stacks together to work this out.

And if any developers that are using the SNMP Research stack want to talk to
me about details, I'm open to setting up a private conversation. Send me
email. (I cannot talk in detail about the code, since it is covered by a
non-disclosure agreement, unless the other person is also covered by the
non-disclosure agreement.)

I would certainly appreciate talking with the SNMP developers at Nortel. Let
me know a time and a place, and I'll try to come visit for a day or two.
Likewise, if anyone else wants to have a developer to developer talk, please
contact me.

I've been doing some serious work on SNMPv3 for the last
few months, and have had many meetings with the developers
from the network management group, and with the security developers. SNMPv3
USM is quite difficult to understand, and email doesn't provide an effective
medium for communication. Packet dumps, working code, multiple screens with
the RFCs are tools that are needed to make progress.

On Tue, 5 Apr 2005, Sharon Chisholm wrote:
> <Wes>
> 
> As do I.  Specifically, I think Robert's ordering of requirements 
> matches mine.  In-band first, and encapsulated being a second choice. 
> As I've mentioned in multiple other messages, there are a large number 
> of issues with out-of-band keying that makes implementation difficult.  
> I suspect Sharon must not agree with any of those other points? </Wes>
> 
> No, not really. After our discussion in Minneapolis where you 
> mentioned the fact that you felt separate key management would be 
> impossible to implement in net-snmp, I went back and talked to some 
> more SNMPv3 implementers to get their view of implementing eUSM and 
> although they observed there were some missing elements of procedure, 
> they saw nothing that they felt would cause implementation problems.
> 
> I'm a big fan of modular architectures. It allows you to add 
> functionality as you need it and to ensures a good return in 
> investment when looking to add new features. Yes, there are points 
> where having too many separate modules to worry about starts to cost 
> more than it saves and then you look at combining things together to 
> get some improvements. I don't think we are there in this particular 
> case.
> 
> Sharon

Regards,
/david t. perkins



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 13:21:23 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17630;
	Tue, 12 Apr 2005 13:21:23 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLPEQ-0007p0-EJ; Tue, 12 Apr 2005 13:31:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLP2K-0004k7-KQ; Tue, 12 Apr 2005 13:18:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLP2J-0004jN-De
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 13:18:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17437
	for <isms@ietf.org>; Tue, 12 Apr 2005 13:18:40 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPBn-0007ic-4m
	for isms@ietf.org; Tue, 12 Apr 2005 13:28:40 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50) id 1DLP1z-0006hr-Nn
	for isms@ietf.org; Tue, 12 Apr 2005 13:18:31 -0400
Date: Tue, 12 Apr 2005 13:19:11 -0400
From: Robert Story <rstory@freesnmp.com>
To: isms@ietf.org
Message-ID: <20050412131911.6b046d6d@aud>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: [Isms] Informal consensus on dropping out of band keying?
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit

We are just about half-way to our next dead-line, and I don't get the sense
that we are making much progress. If we could narrow the discussion down to 2
architectures, instead of 3, that would be some progress.

Ken posted the three architectures for discussion on 3/18. Since then, there
hasn't been too much discussion. I've summarized the preferences for people who
have expressed one. If I mis-characterized your preference, please let me know.


(OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate keying)

Wes Hardaker expressed a preference for IBK or EK.
Kaushik Narayan expressed a preference for EK or IBK.
Sharon Chisholm epxressed a preference for OOBK.
Uri Blumenthal expressed a preference for IBK.
Robert Story expressed a preference for IBK or EK.
Ira McDonald expressed a preference for IBK (or at least not OOBK).

So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok, and 3
also said EK would be ok.

If you haven't expressed a preference for one or two of the
architectures, now would be a good time to do so.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 13:35:40 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19008;
	Tue, 12 Apr 2005 13:35:40 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLPSG-0008Fb-1K; Tue, 12 Apr 2005 13:45:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLPID-00080S-GK; Tue, 12 Apr 2005 13:35:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPIB-0007zp-MU
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 13:35:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18959
	for <isms@ietf.org>; Tue, 12 Apr 2005 13:35:04 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLPRf-0008DC-74
	for isms@ietf.org; Tue, 12 Apr 2005 13:45:04 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id C467011D9FB; Tue, 12 Apr 2005 10:34:59 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
Organization: Sparta
References: <20050412131911.6b046d6d@aud>
Date: Tue, 12 Apr 2005 10:34:58 -0700
In-Reply-To: <20050412131911.6b046d6d@aud> (Robert Story's message of "Tue, 12
	Apr 2005 13:19:11 -0400")
Message-ID: <sdll7n99vh.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

>>>>> On Tue, 12 Apr 2005 13:19:11 -0400, Robert Story <rstory@freesnmp.com> said:

Robert> We are just about half-way to our next dead-line, and I don't
Robert> get the sense that we are making much progress. If we could
Robert> narrow the discussion down to 2 architectures, instead of 3,
Robert> that would be some progress.

Good summary, thanks.  I suspected that's about where things lay.
However, I think you must have missed at least a few opinions that
might be discernible from comments (Juergen's S. for example I know
has posted a fair amount, though I don't remember which he agreed with
or disagreed with; I know that David P. is in favor of IBK but I'm not
sure of his opinions on the other 2).

I do wonder if we should consider having an interim in late May?  I'm
not sure where we could hold it and how many people would be
interested, but I suspect it would help to make progress.


-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 13:41:26 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19396;
	Tue, 12 Apr 2005 13:41:26 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLPXq-0008PK-GI; Tue, 12 Apr 2005 13:51:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLPLz-0000IF-IA; Tue, 12 Apr 2005 13:39:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPLy-0000Hw-23
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 13:39:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19214
	for <isms@ietf.org>; Tue, 12 Apr 2005 13:38:58 -0400 (EDT)
Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPVR-0008LB-LE
	for isms@ietf.org; Tue, 12 Apr 2005 13:48:59 -0400
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com
	[172.29.225.253])
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3CHcbrH021674;
	Tue, 12 Apr 2005 10:38:37 -0700 (PDT)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service
	(5.5.2657.72) id <2R3AG6Y5>; Tue, 12 Apr 2005 10:38:38 -0700
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7B4B@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'Robert Story'" <rstory@freesnmp.com>, isms@ietf.org
Subject: RE: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 10:38:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da

Hi,

Strongly favor IBK.  
Would accept (unhappily) EBK.
Strongly opposed to OBK.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org]On
> Behalf Of Robert Story
> Sent: Tuesday, April 12, 2005 1:19 PM
> To: isms@ietf.org
> Subject: [Isms] Informal consensus on dropping out of band keying?
> 
> 
> We are just about half-way to our next dead-line, and I don't 
> get the sense
> that we are making much progress. If we could narrow the 
> discussion down to 2
> architectures, instead of 3, that would be some progress.
> 
> Ken posted the three architectures for discussion on 3/18. 
> Since then, there
> hasn't been too much discussion. I've summarized the 
> preferences for people who
> have expressed one. If I mis-characterized your preference, 
> please let me know.
> 
> 
> (OOBK = Out of band keying, IBK = In band keying, EK = 
> Encapsulate keying)
> 
> Wes Hardaker expressed a preference for IBK or EK.
> Kaushik Narayan expressed a preference for EK or IBK.
> Sharon Chisholm epxressed a preference for OOBK.
> Uri Blumenthal expressed a preference for IBK.
> Robert Story expressed a preference for IBK or EK.
> Ira McDonald expressed a preference for IBK (or at least not OOBK).
> 
> So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK 
> would be ok, and 3
> also said EK would be ok.
> 
> If you haven't expressed a preference for one or two of the
> architectures, now would be a good time to do so.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 13:59:26 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20484;
	Tue, 12 Apr 2005 13:59:26 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLPpD-0000Ti-Sk; Tue, 12 Apr 2005 14:09:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLPbn-0003pw-6y; Tue, 12 Apr 2005 13:55:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPbl-0003pZ-SB
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 13:55:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20249
	for <isms@ietf.org>; Tue, 12 Apr 2005 13:55:20 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPlD-0000NH-W2
	for isms@ietf.org; Tue, 12 Apr 2005 14:05:18 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3CHt3tI003474; 
	Tue, 12 Apr 2005 17:55:03 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3CHsl1w003324; 
	Tue, 12 Apr 2005 17:55:03 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041210550209711 ; Tue, 12 Apr 2005 10:55:02 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 12 Apr 2005 10:55:02 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 12 Apr 2005 10:55:02 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 12 Apr 2005 13:54:57 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 13:54:35 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929F69F21@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Informal consensus on dropping out of band keying?
Thread-Index: AcU/hKeNQ7q1jwRRQaS8FFiJtADRDwAA9HDQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Robert Story" <rstory@freesnmp.com>, <isms@ietf.org>
X-OriginalArrivalTime: 12 Apr 2005 17:54:57.0777 (UTC)
	FILETIME=[BD86FE10:01C53F88]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: quoted-printable

For me *both* encapsulated and inband are OK. So count me in "at least
not OOBK".

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Robert Story
Sent: Tuesday, April 12, 2005 10:19 AM
To: isms@ietf.org
Subject: [Isms] Informal consensus on dropping out of band keying?

We are just about half-way to our next dead-line, and I don't get the
sense
that we are making much progress. If we could narrow the discussion down
to 2
architectures, instead of 3, that would be some progress.

Ken posted the three architectures for discussion on 3/18. Since then,
there
hasn't been too much discussion. I've summarized the preferences for
people who
have expressed one. If I mis-characterized your preference, please let
me know.


(OOBK =3D Out of band keying, IBK =3D In band keying, EK =3D Encapsulate
keying)

Wes Hardaker expressed a preference for IBK or EK.
Kaushik Narayan expressed a preference for EK or IBK.
Sharon Chisholm epxressed a preference for OOBK.
Uri Blumenthal expressed a preference for IBK.
Robert Story expressed a preference for IBK or EK.
Ira McDonald expressed a preference for IBK (or at least not OOBK).

So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok,
and 3
also said EK would be ok.

If you haven't expressed a preference for one or two of the
architectures, now would be a good time to do so.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 15:01:01 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25489;
	Tue, 12 Apr 2005 15:01:01 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLQmq-0002HT-Ho; Tue, 12 Apr 2005 15:11:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLQbh-0005qL-GQ; Tue, 12 Apr 2005 14:59:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQbf-0005om-RH
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 14:59:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25373
	for <isms@ietf.org>; Tue, 12 Apr 2005 14:59:17 -0400 (EDT)
Received: from i93d6.i.pppool.de ([85.73.147.214] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQlA-0002Dc-8X
	for isms@ietf.org; Tue, 12 Apr 2005 15:09:17 -0400
Received: by boskop.local (Postfix, from userid 501)
	id 8B64725F78F; Tue, 12 Apr 2005 20:58:56 +0200 (CEST)
Date: Tue, 12 Apr 2005 20:58:56 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Wes Hardaker <hardaker@tislabs.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
Message-ID: <20050412185856.GA7981@boskop.local>
Mail-Followup-To: Wes Hardaker <hardaker@tislabs.com>,
	Robert Story <rstory@freesnmp.com>, isms@ietf.org
References: <20050412131911.6b046d6d@aud> <sdll7n99vh.fsf@wes.hardakers.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <sdll7n99vh.fsf@wes.hardakers.net>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

On Tue, Apr 12, 2005 at 10:34:58AM -0700, Wes Hardaker wrote:
 
> Good summary, thanks.  I suspected that's about where things lay.
> However, I think you must have missed at least a few opinions that
> might be discernible from comments (Juergen's S. for example I know
> has posted a fair amount, though I don't remember which he agreed with
> or disagreed with; I know that David P. is in favor of IBK but I'm not
> sure of his opinions on the other 2).

I am in favor of "encapsulation keying" but could also live with a
out-of-band keying solution if it really solves the integration
problem without introducing a rather complex machinery.
 
/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 15:18:23 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27625;
	Tue, 12 Apr 2005 15:18:23 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLR3f-0002ku-Da; Tue, 12 Apr 2005 15:28:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLQmV-00087M-9T; Tue, 12 Apr 2005 15:10:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQmT-00083a-Qt
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 15:10:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26567
	for <isms@ietf.org>; Tue, 12 Apr 2005 15:09:55 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQvR-0002WE-TO
	for isms@ietf.org; Tue, 12 Apr 2005 15:19:55 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3CJ9aW00143
	for <isms@ietf.org>; Tue, 12 Apr 2005 15:09:36 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3CJ9bK06207
	for <isms@ietf.org>; Tue, 12 Apr 2005 15:09:37 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3R26M5>; Tue, 12 Apr 2005 15:09:35 -0400
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4030B8D86@zcarhxm2.corp.nortel.com>
From: "Sharon Chisholm" <schishol@nortel.com>
To: isms@ietf.org
Subject: RE: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 15:09:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69

hi

I think those are the two solutions with the best chance of providing
something that can also be leveraged in netconf.

Sharon

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Juergen Schoenwaelder
Sent: Tuesday, April 12, 2005 2:59 PM
To: Wes Hardaker
Cc: isms@ietf.org
Subject: Re: [Isms] Informal consensus on dropping out of band keying?


On Tue, Apr 12, 2005 at 10:34:58AM -0700, Wes Hardaker wrote:
 
> Good summary, thanks.  I suspected that's about where things lay. 
> However, I think you must have missed at least a few opinions that 
> might be discernible from comments (Juergen's S. for example I know 
> has posted a fair amount, though I don't remember which he agreed with 
> or disagreed with; I know that David P. is in favor of IBK but I'm not 
> sure of his opinions on the other 2).

I am in favor of "encapsulation keying" but could also live with a
out-of-band keying solution if it really solves the integration problem
without introducing a rather complex machinery.
 
/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 16:47:09 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09377;
	Tue, 12 Apr 2005 16:47:09 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLSRY-0006xv-9E; Tue, 12 Apr 2005 16:57:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLS3u-0003e5-2S; Tue, 12 Apr 2005 16:32:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLS3t-0003cu-4C
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 16:32:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07468
	for <isms@ietf.org>; Tue, 12 Apr 2005 16:32:25 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSDK-0006FN-4e
	for isms@ietf.org; Tue, 12 Apr 2005 16:42:26 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3CKWIsC015081; 
	Tue, 12 Apr 2005 13:32:18 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3CKVlwc023098;
	Tue, 12 Apr 2005 13:31:47 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3CKVlkH023094; Tue, 12 Apr 2005 13:31:47 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Tue, 12 Apr 2005 13:31:47 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Sharon Chisholm <schishol@nortel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4030B8926@zcarhxm2.corp.nortel.com>
Message-ID: <Pine.LNX.4.10.10504121320290.12376-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2

HI,

Working code is a tradition in the IETF.

You haven't provided any costs and benefits
with using one architecture approach over
another. 

What I'm suggesting is a validation of the
consequences of each approach. How would
you do this? I'm open to any approach that
addresses the problem of driving the
deployment (initial installation and
ongoing operational cost) of a secure
SNMP to a low enough number so that
it will be cost effective to use.

Please provide an actionable approach
that will provide some insights with
a reasonable amount of certainty.

Again....
> I've been doing some serious work on SNMPv3 for the last
> few months, and have had many meetings with the developers
> from the network management group, and with the security developers.
> SNMPv3 USM is quite difficult to understand, and email doesn't
> provide an effective medium for communication. Packet dumps,
> working code, multiple screens with the RFCs are tools that
> are needed to make progress.

Regards,
/david t. perkins

On Tue, 12 Apr 2005, Sharon Chisholm wrote:
> hi
> 
> Somehow using a code inspection to determine the correct architecture seems
> very wrong to me.
> 
> Sharon
> 
> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> Sent: Tuesday, April 05, 2005 3:49 PM
> To: Chisholm, Sharon [CAR:5K50:EXCH]
> Cc: isms@ietf.org
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> HI,
> 
> Lets set up a conference call to talk this through.
> 
> Wes knows the internals of NET-SNMP. I've been going through the SNMP
> Research code. Hopefully we can get some other developers with knowledge of
> other SNMP stacks together to work this out.
> 
> And if any developers that are using the SNMP Research stack want to talk to
> me about details, I'm open to setting up a private conversation. Send me
> email. (I cannot talk in detail about the code, since it is covered by a
> non-disclosure agreement, unless the other person is also covered by the
> non-disclosure agreement.)
> 
> I would certainly appreciate talking with the SNMP developers at Nortel. Let
> me know a time and a place, and I'll try to come visit for a day or two.
> Likewise, if anyone else wants to have a developer to developer talk, please
> contact me.
> 
> I've been doing some serious work on SNMPv3 for the last
> few months, and have had many meetings with the developers
> from the network management group, and with the security developers. SNMPv3
> USM is quite difficult to understand, and email doesn't provide an effective
> medium for communication. Packet dumps, working code, multiple screens with
> the RFCs are tools that are needed to make progress.
> 
> On Tue, 5 Apr 2005, Sharon Chisholm wrote:
> > <Wes>
> > 
> > As do I.  Specifically, I think Robert's ordering of requirements 
> > matches mine.  In-band first, and encapsulated being a second choice. 
> > As I've mentioned in multiple other messages, there are a large number 
> > of issues with out-of-band keying that makes implementation difficult.  
> > I suspect Sharon must not agree with any of those other points? </Wes>
> > 
> > No, not really. After our discussion in Minneapolis where you 
> > mentioned the fact that you felt separate key management would be 
> > impossible to implement in net-snmp, I went back and talked to some 
> > more SNMPv3 implementers to get their view of implementing eUSM and 
> > although they observed there were some missing elements of procedure, 
> > they saw nothing that they felt would cause implementation problems.
> > 
> > I'm a big fan of modular architectures. It allows you to add 
> > functionality as you need it and to ensures a good return in 
> > investment when looking to add new features. Yes, there are points 
> > where having too many separate modules to worry about starts to cost 
> > more than it saves and then you look at combining things together to 
> > get some improvements. I don't think we are there in this particular 
> > case.
> > 
> > Sharon
> 
> Regards,
> /david t. perkins
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 17:08:18 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11576;
	Tue, 12 Apr 2005 17:08:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLSlz-0007uu-I8; Tue, 12 Apr 2005 17:18:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLRFo-0003tu-H1; Tue, 12 Apr 2005 15:40:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRFn-0003t5-3B
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 15:40:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29616
	for <isms@ietf.org>; Tue, 12 Apr 2005 15:40:44 -0400 (EDT)
Message-Id: <200504121940.PAA29616@ietf.org>
Received: from rwcrmhc13.comcast.net ([204.127.198.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRPH-0003NI-NJ
	for isms@ietf.org; Tue, 12 Apr 2005 15:50:45 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc13) with SMTP
	id <2005041219403501500h16m4e>; Tue, 12 Apr 2005 19:40:35 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Wes Hardaker'" <hardaker@tislabs.com>,
        "'Robert Story'" <rstory@freesnmp.com>
Subject: RE: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 15:40:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <sdll7n99vh.fsf@wes.hardakers.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcU/hg06yDfOR4O9Rga4+I9UeSbvxAAAbB8g
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit

Hi,

I support the encapsulated approach, because that approach is
consistent with how many other IETF keying and security problems are
being resolved already, and we need to avoid reinventing the wheel for
SNMP. 

I expect that in the future, the fact that there are many solutions
now using or moving toward encapsulation for security will drive
improved standardization of the security protocols involved, and SNMP
should be ready to also converge on those standard solutions. I think
an encapsulated approach should focus on utilizing IETF standardized
layer 7 interfaces for encapsulated security and transport, such as
SASL, BEEP, or SSH.

For encapsulated; not much interested in the other architectures.

dbh

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker
> Sent: Tuesday, April 12, 2005 1:35 PM
> To: Robert Story
> Cc: isms@ietf.org
> Subject: Re: [Isms] Informal consensus on dropping out of band
keying?
> 
> >>>>> On Tue, 12 Apr 2005 13:19:11 -0400, Robert Story 
> <rstory@freesnmp.com> said:
> 
> Robert> We are just about half-way to our next dead-line, and I
don't
> Robert> get the sense that we are making much progress. If we could
> Robert> narrow the discussion down to 2 architectures, instead of 3,
> Robert> that would be some progress.
> 
> Good summary, thanks.  I suspected that's about where things lay.
> However, I think you must have missed at least a few opinions that
> might be discernible from comments (Juergen's S. for example I know
> has posted a fair amount, though I don't remember which he agreed
with
> or disagreed with; I know that David P. is in favor of IBK but I'm
not
> sure of his opinions on the other 2).
> 
> I do wonder if we should consider having an interim in late May?
I'm
> not sure where we could hold it and how many people would be
> interested, but I suspect it would help to make progress.
> 
> 
> -- 
> Wes Hardaker
> Sparta, Inc.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 17:09:16 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11776;
	Tue, 12 Apr 2005 17:09:16 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLSmw-000809-MU; Tue, 12 Apr 2005 17:19:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLS9b-0004Po-3h; Tue, 12 Apr 2005 16:38:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLS9Z-0004PO-Iu
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 16:38:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08232
	for <isms@ietf.org>; Tue, 12 Apr 2005 16:38:23 -0400 (EDT)
Received: from carter-zimmerman.mit.edu ([18.18.3.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSJ4-0006Wj-W6
	for isms@ietf.org; Tue, 12 Apr 2005 16:48:24 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 562B0E0063; Tue, 12 Apr 2005 16:38:26 -0400 (EDT)
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
References: <20050412131911.6b046d6d@aud>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Tue, 12 Apr 2005 16:38:26 -0400
In-Reply-To: <20050412131911.6b046d6d@aud> (Robert Story's message of "Tue,
	12 Apr 2005 13:19:11 -0400")
Message-ID: <tslwtr77mt9.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

Hi.  I'd like to express a personal preference for encapsulation
followed by IBK.  I think OBK can be made to work and if that were the
group's choice, that would be doable.  However OBK seems like it will
have a lot of issues because you will need to integrate the key
management protocol and the SNMP protocol.  OBK seems the least like
the approaches we have chosen for applications similar to SNMP.

That said, OBK does seem similar to the approach we chose for IPsec.
So the IETF does have experience with OBK-like approaches.

I favor encapsulation because it seems to be the closest fit to the
approach commonly taken in the apps area.  That approach seems to work
quite well and I'd expect it to work here.  I also would expect it to
allow significant reuse of code.

IBK seems like it can work too.  I think it would be a fine approach.
I think making IBK work will be somewhat more involved than
encapsulation.


--Sam

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 17:15:26 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12437;
	Tue, 12 Apr 2005 17:15:26 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLSsw-0008E8-Ig; Tue, 12 Apr 2005 17:25:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLS7q-0004Fg-NA; Tue, 12 Apr 2005 16:36:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLS7q-0004B8-8z
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 16:36:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07957
	for <isms@ietf.org>; Tue, 12 Apr 2005 16:35:27 -0400 (EDT)
Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSGF-0006Pg-47
	for isms@ietf.org; Tue, 12 Apr 2005 16:45:28 -0400
Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122]
	helo=oemcomputer)
	by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DLS6U-0005zE-00
	for isms@ietf.org; Tue, 12 Apr 2005 13:35:22 -0700
Message-ID: <002201c53f9f$5aeda1c0$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <20050412131911.6b046d6d@aud>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 13:36:50 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

hi -

> From: "Robert Story" <rstory@freesnmp.com>
> To: <isms@ietf.org>
> Sent: Tuesday, April 12, 2005 10:19 AM
> Subject: [Isms] Informal consensus on dropping out of band keying?
...
> (OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate keying)
...

Do you consider using existing USM key establishment as OOBK or IBK?
It's out-of-band in that it is not necessarily tied to the "session" that
uses a key.  It's in-band in the sense that it's done using SNMPv3
and not tied to other protocols.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 17:22:58 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12986;
	Tue, 12 Apr 2005 17:22:58 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLT0F-0008Sk-Pi; Tue, 12 Apr 2005 17:33:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLRzq-0003KB-HN; Tue, 12 Apr 2005 16:28:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRu5-0001jb-4c
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 16:22:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05504
	for <isms@ietf.org>; Tue, 12 Apr 2005 16:22:22 -0400 (EDT)
Received: from carter-zimmerman.mit.edu ([18.18.3.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLS3a-0005d4-0s
	for isms@ietf.org; Tue, 12 Apr 2005 16:32:23 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 14929E0063; Tue, 12 Apr 2005 16:22:24 -0400 (EDT)
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil>
	<Pine.LNX.4.10.10503181645290.429-100000@shell4.bayarea.net>
	<20050321170043.39f3e05f@aud>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Tue, 12 Apr 2005 16:22:24 -0400
In-Reply-To: <20050321170043.39f3e05f@aud> (Robert Story's message of "Mon,
	21 Mar 2005 17:00:43 -0500")
Message-ID: <tsl1x9f924f.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

>>>>> "Robert" == Robert Story <rstory@freesnmp.com> writes:

    Robert> On Fri, 18 Mar 2005 17:26:22 -0800 (PST) David wrote:
    DTP> On Fri, 18 Mar 2005, Ken Hornstein wrote: > - "Encapsulation
    DTP> keying"
    DTP> > 
    DTP> > This is the approach taken by TLSM.  An encapsulation
    DTP> protocol (such > as TLS) is used to "wrap" SNMP payloads.

    DTP> 2) Setting up sessions for delivering notifications.

    Robert> Speaking of notifications, isn't there an issue with the
    Robert> transport approach and notifications? Doesn't net-conf
    Robert> suffer from this issue? Specifically, sending a
    Robert> notification when the notification destination doesn't
    Robert> have an existing open session with the notification
    Robert> generator.

Why is this true?  If all engines have credentials they can use, why can't you open a session if you need one?

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 17:23:45 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13199;
	Tue, 12 Apr 2005 17:23:44 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLT10-00006e-GD; Tue, 12 Apr 2005 17:33:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLSqJ-0001tW-5m; Tue, 12 Apr 2005 17:22:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSqI-0001sl-3z
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 17:22:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12929
	for <isms@ietf.org>; Tue, 12 Apr 2005 17:22:31 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSzo-0008S3-RD
	for isms@ietf.org; Tue, 12 Apr 2005 17:32:33 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-4.cisco.com with ESMTP; 12 Apr 2005 14:22:25 -0700
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com
	[171.71.163.34])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3CLMHfI012098;
	Tue, 12 Apr 2005 14:22:17 -0700 (PDT)
Received: from kaushik-w2k03.cisco.com ([171.69.75.179])
	by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZY10210;
	Tue, 12 Apr 2005 14:22:21 -0700 (PDT)
Message-Id: <6.2.0.14.0.20050412141750.0425aa28@mira-sjc5-a.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 12 Apr 2005 14:22:20 -0700
To: Robert Story <rstory@freesnmp.com>
From: Kaushik Narayan <kaushik@cisco.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
In-Reply-To: <20050412131911.6b046d6d@aud>
References: <20050412131911.6b046d6d@aud>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081

Hi Robert,

I would like to clarify that the EUSM proposal currently uses OOBK and that was
our first preference. We are willing to use IBK in the interest of making 
progress.

I hope that we are not voting here.

regards,
   kaushik!


At 10:19 AM 4/12/2005, Robert Story wrote:
>We are just about half-way to our next dead-line, and I don't get the sense
>that we are making much progress. If we could narrow the discussion down to 2
>architectures, instead of 3, that would be some progress.
>
>Ken posted the three architectures for discussion on 3/18. Since then, there
>hasn't been too much discussion. I've summarized the preferences for 
>people who
>have expressed one. If I mis-characterized your preference, please let me 
>know.
>
>
>(OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate keying)
>
>Wes Hardaker expressed a preference for IBK or EK.
>Kaushik Narayan expressed a preference for EK or IBK.
>Sharon Chisholm epxressed a preference for OOBK.
>Uri Blumenthal expressed a preference for IBK.
>Robert Story expressed a preference for IBK or EK.
>Ira McDonald expressed a preference for IBK (or at least not OOBK).
>
>So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok, and 3
>also said EK would be ok.
>
>If you haven't expressed a preference for one or two of the
>architectures, now would be a good time to do so.
>
>_______________________________________________
>Isms mailing list
>Isms@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 17:37:30 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14686;
	Tue, 12 Apr 2005 17:37:29 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLTEI-0000gD-Rb; Tue, 12 Apr 2005 17:47:31 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLSuj-0002XF-5h; Tue, 12 Apr 2005 17:27:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSuh-0002WU-U7
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 17:27:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13407
	for <isms@ietf.org>; Tue, 12 Apr 2005 17:27:05 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLT4D-0000By-K6
	for isms@ietf.org; Tue, 12 Apr 2005 17:37:06 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3CLQqsC001792; 
	Tue, 12 Apr 2005 14:26:52 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3CLQKLr005528;
	Tue, 12 Apr 2005 14:26:20 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3CLQKvL005522; Tue, 12 Apr 2005 14:26:20 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Tue, 12 Apr 2005 14:26:20 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
In-Reply-To: <20050412131911.6b046d6d@aud>
Message-ID: <Pine.LNX.4.10.10504121401330.12376-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

HI,

Summarizing from an earlier message...

I'm open to any approach that
addresses the problem of driving the
deployment (initial installation and
ongoing operational cost) of a secure
SNMP to a low enough number so that
it will be cost effective to use.

I feel that any choice without enough
investigation to determine a reasonable
ammount of certainty is unwise.

I learned much about security technology
and security politics at the last
IETF, and feel at this point in time that
the only viable approach is to use the
same UDP port that is used by a command
responder and a notification receiver.

Both Inband and Encapsulation can use
the same UDP port. However, I believe
that it might be much harder for an
"off the self" encapsulation library
to be adapted to share a UDP port
with "straight SNMP". Also, I've
worked with one SSL/TLS library,
and found it quite difficult to
use and bloated. In addition, the
state information that is kept,
and the modifications that are needed
to use it are approximately the
same that would be needed to
use an inband approach. I heard
EricR's fear about the potential for
not getting correct a re-implementation
of an existing security approach
with an inband new security model.
Without coding both the inband
and encapsulation, I find it
difficult to come to a conclusion
with a high degree of certainty.

However, at this point, I feel that
an inband architecture is better, since
I don't believe that any security
hole will be openned reusing an
known security approach. I believe
that the advantages of using an
encapsulation approach are in fact
disadvantages.

Regards,
/david t. perkins



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 22:35:39 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06633;
	Tue, 12 Apr 2005 22:35:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLXss-00086V-RN; Tue, 12 Apr 2005 22:45:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLXiG-00040w-Cg; Tue, 12 Apr 2005 22:34:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLXiE-00040G-Sg
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 22:34:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06605
	for <isms@ietf.org>; Tue, 12 Apr 2005 22:34:32 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLXrn-00084S-GR
	for isms@ietf.org; Tue, 12 Apr 2005 22:44:36 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50)
	id 1DLXi3-0008G4-1T; Tue, 12 Apr 2005 22:34:31 -0400
Date: Tue, 12 Apr 2005 22:35:31 -0400
From: Robert Story <rstory@freesnmp.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
Message-ID: <20050412223531.2f814705@aud>
In-Reply-To: <002201c53f9f$5aeda1c0$7f1afea9@oemcomputer>
References: <20050412131911.6b046d6d@aud>
	<002201c53f9f$5aeda1c0$7f1afea9@oemcomputer>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit

On Tue, 12 Apr 2005 13:36:50 -0700 Randy wrote:
RP> > From: "Robert Story" <rstory@freesnmp.com>
RP> ...
RP> > (OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate
RP> > keying)
RP> ...
RP> 
RP> Do you consider using existing USM key establishment as OOBK or IBK?
RP> It's out-of-band in that it is not necessarily tied to the "session" that
RP> uses a key.  It's in-band in the sense that it's done using SNMPv3
RP> and not tied to other protocols.

I was simply using the same terminology that Ken used in his original message.

Personally, I'd consider it in-band.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 22:50:25 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07784;
	Tue, 12 Apr 2005 22:50:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLY7A-0008Qg-V8; Tue, 12 Apr 2005 23:00:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLXw4-0006rN-I2; Tue, 12 Apr 2005 22:49:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLXw3-0006lx-2S
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 22:48:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07597
	for <isms@ietf.org>; Tue, 12 Apr 2005 22:48:51 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLY5e-0008OB-Nl
	for isms@ietf.org; Tue, 12 Apr 2005 22:58:55 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50)
	id 1DLXvu-0008IP-Dm; Tue, 12 Apr 2005 22:48:50 -0400
Date: Tue, 12 Apr 2005 22:49:50 -0400
From: Robert Story <rstory@freesnmp.com>
To: Kaushik Narayan <kaushik@cisco.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
Message-ID: <20050412224950.15bf84d3@aud>
In-Reply-To: <6.2.0.14.0.20050412141750.0425aa28@mira-sjc5-a.cisco.com>
References: <20050412131911.6b046d6d@aud>
	<6.2.0.14.0.20050412141750.0425aa28@mira-sjc5-a.cisco.com>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit

On Tue, 12 Apr 2005 14:22:20 -0700 Kaushik wrote:
KN> I hope that we are not voting here.

No, which is why I very deliberately used 'informal' in the subject. I have no
authority to call for a vote. It just seemed too quiet in here. With a rapidly
approaching deadline, I just wanted to try and get things moving again.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 22:53:25 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08571;
	Tue, 12 Apr 2005 22:53:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLYA5-000060-I7; Tue, 12 Apr 2005 23:03:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLXyo-0007NI-1Y; Tue, 12 Apr 2005 22:51:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLXyl-0007LM-5D
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 22:51:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07959
	for <isms@ietf.org>; Tue, 12 Apr 2005 22:51:39 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLY8N-0008UK-Lb
	for isms@ietf.org; Tue, 12 Apr 2005 23:01:44 -0400
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3D2pS514512; Tue, 12 Apr 2005 22:51:28 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j3D2pQL18958; Tue, 12 Apr 2005 22:51:26 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJA8R>; Tue, 12 Apr 2005 22:51:27 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9AF3@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>,
        Robert Story <rstory@freesnmp.com>
Subject: RE: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 22:51:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1990922654=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1990922654==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C53FD3.9586D7DF"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C53FD3.9586D7DF
Content-Type: text/plain

What specific applications similar to SNMP are you thinking of?

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> Behalf Of Sam Hartman
> Sent: April 12, 2005 4:38 PM
> To: Robert Story
> Cc: isms@ietf.org
> Subject: Re: [Isms] Informal consensus on dropping out of band keying?
> 
> Hi.  I'd like to express a personal preference for encapsulation
> followed by IBK.  I think OBK can be made to work and if that were the
> group's choice, that would be doable.  However OBK seems like it will
> have a lot of issues because you will need to integrate the key
> management protocol and the SNMP protocol.  OBK seems the least like
> the approaches we have chosen for applications similar to SNMP.
> 
> That said, OBK does seem similar to the approach we chose for IPsec.
> So the IETF does have experience with OBK-like approaches.
> 
> I favor encapsulation because it seems to be the closest fit to the
> approach commonly taken in the apps area.  That approach seems to work
> quite well and I'd expect it to work here.  I also would expect it to
> allow significant reuse of code.
> 
> IBK seems like it can work too.  I think it would be a fine approach.
> I think making IBK work will be somewhat more involved than
> encapsulation.
> 
> 
> --Sam
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C53FD3.9586D7DF
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Informal consensus on dropping out of band =
keying?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>What specific applications similar to SNMP are you =
thinking of?</FONT>
</P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On</FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of Sam Hartman</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 12, 2005 4:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Robert Story</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Isms] Informal consensus on =
dropping out of band keying?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi.&nbsp; I'd like to express a personal =
preference for encapsulation</FONT>
<BR><FONT SIZE=3D2>&gt; followed by IBK.&nbsp; I think OBK can be made =
to work and if that were the</FONT>
<BR><FONT SIZE=3D2>&gt; group's choice, that would be doable.&nbsp; =
However OBK seems like it will</FONT>
<BR><FONT SIZE=3D2>&gt; have a lot of issues because you will need to =
integrate the key</FONT>
<BR><FONT SIZE=3D2>&gt; management protocol and the SNMP =
protocol.&nbsp; OBK seems the least like</FONT>
<BR><FONT SIZE=3D2>&gt; the approaches we have chosen for applications =
similar to SNMP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That said, OBK does seem similar to the =
approach we chose for IPsec.</FONT>
<BR><FONT SIZE=3D2>&gt; So the IETF does have experience with OBK-like =
approaches.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I favor encapsulation because it seems to be =
the closest fit to the</FONT>
<BR><FONT SIZE=3D2>&gt; approach commonly taken in the apps area.&nbsp; =
That approach seems to work</FONT>
<BR><FONT SIZE=3D2>&gt; quite well and I'd expect it to work =
here.&nbsp; I also would expect it to</FONT>
<BR><FONT SIZE=3D2>&gt; allow significant reuse of code.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; IBK seems like it can work too.&nbsp; I think =
it would be a fine approach.</FONT>
<BR><FONT SIZE=3D2>&gt; I think making IBK work will be somewhat more =
involved than</FONT>
<BR><FONT SIZE=3D2>&gt; encapsulation.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --Sam</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C53FD3.9586D7DF--


--===============1990922654==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1990922654==--



From isms-bounces@ietf.org  Tue Apr 12 23:12:53 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10313;
	Tue, 12 Apr 2005 23:12:53 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLYSv-0000Zg-Ul; Tue, 12 Apr 2005 23:22:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLYIG-0003Jk-HC; Tue, 12 Apr 2005 23:11:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLYIE-0003Fa-95
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 23:11:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10024
	for <isms@ietf.org>; Tue, 12 Apr 2005 23:11:49 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLYRt-0000Xa-AT
	for isms@ietf.org; Tue, 12 Apr 2005 23:21:54 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3D3BdW20681; Tue, 12 Apr 2005 23:11:39 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3D3BeV13101; Tue, 12 Apr 2005 23:11:40 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJA09>; Tue, 12 Apr 2005 23:11:38 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9AF6@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'David T. Perkins'" <dperkins@dsperkins.com>,
        "Sharon Chisholm" <schishol@nortel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 12 Apr 2005 23:11:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1775044242=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1775044242==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C53FD6.7B8A13E9"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C53FD6.7B8A13E9
Content-Type: text/plain

We would need to work through the effort involved in each implementation to
judge which is more easily implementable, but I'm not sure that's possible
at the abstract level of "should we use OOBK, IBK, or EBK". Are there any
arguments that show there is a significant difference in implementation of
these architectures that we can all agree on? I doubt it, since I think OOBK
is the cheapest to implement and others on the list obviously differ in
opinion. Would it be useful to break down what the major elements of
implementation would be for each approach and lay them out for comparison?

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> Behalf Of David T. Perkins
> Sent: April 12, 2005 4:32 PM
> To: Chisholm, Sharon [CAR:5K50:EXCH]
> Cc: isms@ietf.org
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> HI,
> 
> Working code is a tradition in the IETF.
> 
> You haven't provided any costs and benefits
> with using one architecture approach over
> another.
> 
> What I'm suggesting is a validation of the
> consequences of each approach. How would
> you do this? I'm open to any approach that
> addresses the problem of driving the
> deployment (initial installation and
> ongoing operational cost) of a secure
> SNMP to a low enough number so that
> it will be cost effective to use.
> 
> Please provide an actionable approach
> that will provide some insights with
> a reasonable amount of certainty.
> 
> Again....
> > I've been doing some serious work on SNMPv3 for the last
> > few months, and have had many meetings with the developers
> > from the network management group, and with the security developers.
> > SNMPv3 USM is quite difficult to understand, and email doesn't
> > provide an effective medium for communication. Packet dumps,
> > working code, multiple screens with the RFCs are tools that
> > are needed to make progress.
> 
> Regards,
> /david t. perkins
> 
> On Tue, 12 Apr 2005, Sharon Chisholm wrote:
> > hi
> >
> > Somehow using a code inspection to determine the correct architecture
> seems
> > very wrong to me.
> >
> > Sharon
> >
> > -----Original Message-----
> > From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > Sent: Tuesday, April 05, 2005 3:49 PM
> > To: Chisholm, Sharon [CAR:5K50:EXCH]
> > Cc: isms@ietf.org
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> >
> >
> > HI,
> >
> > Lets set up a conference call to talk this through.
> >
> > Wes knows the internals of NET-SNMP. I've been going through the SNMP
> > Research code. Hopefully we can get some other developers with knowledge
> of
> > other SNMP stacks together to work this out.
> >
> > And if any developers that are using the SNMP Research stack want to
> talk to
> > me about details, I'm open to setting up a private conversation. Send me
> > email. (I cannot talk in detail about the code, since it is covered by a
> > non-disclosure agreement, unless the other person is also covered by the
> > non-disclosure agreement.)
> >
> > I would certainly appreciate talking with the SNMP developers at Nortel.
> Let
> > me know a time and a place, and I'll try to come visit for a day or two.
> > Likewise, if anyone else wants to have a developer to developer talk,
> please
> > contact me.
> >
> > I've been doing some serious work on SNMPv3 for the last
> > few months, and have had many meetings with the developers
> > from the network management group, and with the security developers.
> SNMPv3
> > USM is quite difficult to understand, and email doesn't provide an
> effective
> > medium for communication. Packet dumps, working code, multiple screens
> with
> > the RFCs are tools that are needed to make progress.
> >
> > On Tue, 5 Apr 2005, Sharon Chisholm wrote:
> > > <Wes>
> > >
> > > As do I.  Specifically, I think Robert's ordering of requirements
> > > matches mine.  In-band first, and encapsulated being a second choice.
> > > As I've mentioned in multiple other messages, there are a large number
> > > of issues with out-of-band keying that makes implementation difficult.
> > > I suspect Sharon must not agree with any of those other points? </Wes>
> > >
> > > No, not really. After our discussion in Minneapolis where you
> > > mentioned the fact that you felt separate key management would be
> > > impossible to implement in net-snmp, I went back and talked to some
> > > more SNMPv3 implementers to get their view of implementing eUSM and
> > > although they observed there were some missing elements of procedure,
> > > they saw nothing that they felt would cause implementation problems.
> > >
> > > I'm a big fan of modular architectures. It allows you to add
> > > functionality as you need it and to ensures a good return in
> > > investment when looking to add new features. Yes, there are points
> > > where having too many separate modules to worry about starts to cost
> > > more than it saves and then you look at combining things together to
> > > get some improvements. I don't think we are there in this particular
> > > case.
> > >
> > > Sharon
> >
> > Regards,
> > /david t. perkins
> >
> >
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> >
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C53FD6.7B8A13E9
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>We would need to work through the effort involved in =
each implementation to judge which is more easily implementable, but =
I'm not sure that's possible at the abstract level of &quot;should we =
use OOBK, IBK, or EBK&quot;. Are there any arguments that show there is =
a significant difference in implementation of these architectures that =
we can all agree on? I doubt it, since I think OOBK is the cheapest to =
implement and others on the list obviously differ in opinion. Would it =
be useful to break down what the major elements of implementation would =
be for each approach and lay them out for comparison?</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On</FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of David T. Perkins</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 12, 2005 4:32 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Chisholm, Sharon [CAR:5K50:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; HI,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Working code is a tradition in the IETF.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You haven't provided any costs and =
benefits</FONT>
<BR><FONT SIZE=3D2>&gt; with using one architecture approach =
over</FONT>
<BR><FONT SIZE=3D2>&gt; another.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What I'm suggesting is a validation of =
the</FONT>
<BR><FONT SIZE=3D2>&gt; consequences of each approach. How would</FONT>
<BR><FONT SIZE=3D2>&gt; you do this? I'm open to any approach =
that</FONT>
<BR><FONT SIZE=3D2>&gt; addresses the problem of driving the</FONT>
<BR><FONT SIZE=3D2>&gt; deployment (initial installation and</FONT>
<BR><FONT SIZE=3D2>&gt; ongoing operational cost) of a secure</FONT>
<BR><FONT SIZE=3D2>&gt; SNMP to a low enough number so that</FONT>
<BR><FONT SIZE=3D2>&gt; it will be cost effective to use.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please provide an actionable approach</FONT>
<BR><FONT SIZE=3D2>&gt; that will provide some insights with</FONT>
<BR><FONT SIZE=3D2>&gt; a reasonable amount of certainty.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Again....</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I've been doing some serious work on =
SNMPv3 for the last</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; few months, and have had many meetings =
with the developers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; from the network management group, and =
with the security developers.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SNMPv3 USM is quite difficult to =
understand, and email doesn't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; provide an effective medium for =
communication. Packet dumps,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; working code, multiple screens with the =
RFCs are tools that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are needed to make progress.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; /david t. perkins</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Tue, 12 Apr 2005, Sharon Chisholm =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; hi</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Somehow using a code inspection to =
determine the correct architecture</FONT>
<BR><FONT SIZE=3D2>&gt; seems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; very wrong to me.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: David T. Perkins [<A =
HREF=3D"mailto:dperkins@dsperkins.com">mailto:dperkins@dsperkins.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, April 05, 2005 3:49 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Chisholm, Sharon =
[CAR:5K50:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [Isms] Discussion: =
Architecture direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; HI,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Lets set up a conference call to talk this =
through.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Wes knows the internals of NET-SNMP. I've =
been going through the SNMP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Research code. Hopefully we can get some =
other developers with knowledge</FONT>
<BR><FONT SIZE=3D2>&gt; of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; other SNMP stacks together to work this =
out.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; And if any developers that are using the =
SNMP Research stack want to</FONT>
<BR><FONT SIZE=3D2>&gt; talk to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; me about details, I'm open to setting up a =
private conversation. Send me</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; email. (I cannot talk in detail about the =
code, since it is covered by a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; non-disclosure agreement, unless the other =
person is also covered by the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; non-disclosure agreement.)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I would certainly appreciate talking with =
the SNMP developers at Nortel.</FONT>
<BR><FONT SIZE=3D2>&gt; Let</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; me know a time and a place, and I'll try =
to come visit for a day or two.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Likewise, if anyone else wants to have a =
developer to developer talk,</FONT>
<BR><FONT SIZE=3D2>&gt; please</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; contact me.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I've been doing some serious work on =
SNMPv3 for the last</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; few months, and have had many meetings =
with the developers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; from the network management group, and =
with the security developers.</FONT>
<BR><FONT SIZE=3D2>&gt; SNMPv3</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; USM is quite difficult to understand, and =
email doesn't provide an</FONT>
<BR><FONT SIZE=3D2>&gt; effective</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; medium for communication. Packet dumps, =
working code, multiple screens</FONT>
<BR><FONT SIZE=3D2>&gt; with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the RFCs are tools that are needed to make =
progress.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On Tue, 5 Apr 2005, Sharon Chisholm =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &lt;Wes&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; As do I.&nbsp; Specifically, I think =
Robert's ordering of requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; matches mine.&nbsp; In-band first, =
and encapsulated being a second choice.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; As I've mentioned in multiple other =
messages, there are a large number</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; of issues with out-of-band keying =
that makes implementation difficult.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I suspect Sharon must not agree with =
any of those other points? &lt;/Wes&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; No, not really. After our discussion =
in Minneapolis where you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; mentioned the fact that you felt =
separate key management would be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; impossible to implement in net-snmp, =
I went back and talked to some</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; more SNMPv3 implementers to get their =
view of implementing eUSM and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; although they observed there were =
some missing elements of procedure,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; they saw nothing that they felt would =
cause implementation problems.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I'm a big fan of modular =
architectures. It allows you to add</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; functionality as you need it and to =
ensures a good return in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; investment when looking to add new =
features. Yes, there are points</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; where having too many separate =
modules to worry about starts to cost</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; more than it saves and then you look =
at combining things together to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; get some improvements. I don't think =
we are there in this particular</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; case.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; /david t. perkins</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C53FD6.7B8A13E9--


--===============1775044242==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1775044242==--



From isms-bounces@ietf.org  Tue Apr 12 23:19:25 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11415;
	Tue, 12 Apr 2005 23:19:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLYZF-0000oZ-Jm; Tue, 12 Apr 2005 23:29:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLYMA-0004Fn-Sx; Tue, 12 Apr 2005 23:15:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLYM9-00049T-M0
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 23:15:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10776
	for <isms@ietf.org>; Tue, 12 Apr 2005 23:15:24 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLYVN-0000eX-0J
	for isms@ietf.org; Tue, 12 Apr 2005 23:25:29 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3D3F9W21044; Tue, 12 Apr 2005 23:15:10 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3D3FAV13725; Tue, 12 Apr 2005 23:15:10 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJBAF>; Tue, 12 Apr 2005 23:15:08 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9AF7@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'ietfdbh@comcast.net'" <ietfdbh@comcast.net>,
        "'Wes Hardaker'"
	<hardaker@tislabs.com>,
        "'Robert Story'" <rstory@freesnmp.com>
Subject: RE: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 23:14:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1747471255=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1747471255==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C53FD6.9AC440B3"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C53FD6.9AC440B3
Content-Type: text/plain

Which IETF keying and security problems are being solved with encapsulation
keying other than application transport protocols? I admit that I'm not up
on all the latest protocols, but this seems counter to what I know.

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> Behalf Of David B Harrington
> Sent: April 12, 2005 3:40 PM
> To: 'Wes Hardaker'; 'Robert Story'
> Cc: isms@ietf.org
> Subject: RE: [Isms] Informal consensus on dropping out of band keying?
> 
> Hi,
> 
> I support the encapsulated approach, because that approach is
> consistent with how many other IETF keying and security problems are
> being resolved already, and we need to avoid reinventing the wheel for
> SNMP.
> 
> I expect that in the future, the fact that there are many solutions
> now using or moving toward encapsulation for security will drive
> improved standardization of the security protocols involved, and SNMP
> should be ready to also converge on those standard solutions. I think
> an encapsulated approach should focus on utilizing IETF standardized
> layer 7 interfaces for encapsulated security and transport, such as
> SASL, BEEP, or SSH.
> 
> For encapsulated; not much interested in the other architectures.
> 
> dbh
> 
> > -----Original Message-----
> > From: isms-bounces@lists.ietf.org
> > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker
> > Sent: Tuesday, April 12, 2005 1:35 PM
> > To: Robert Story
> > Cc: isms@ietf.org
> > Subject: Re: [Isms] Informal consensus on dropping out of band
> keying?
> >
> > >>>>> On Tue, 12 Apr 2005 13:19:11 -0400, Robert Story
> > <rstory@freesnmp.com> said:
> >
> > Robert> We are just about half-way to our next dead-line, and I
> don't
> > Robert> get the sense that we are making much progress. If we could
> > Robert> narrow the discussion down to 2 architectures, instead of 3,
> > Robert> that would be some progress.
> >
> > Good summary, thanks.  I suspected that's about where things lay.
> > However, I think you must have missed at least a few opinions that
> > might be discernible from comments (Juergen's S. for example I know
> > has posted a fair amount, though I don't remember which he agreed
> with
> > or disagreed with; I know that David P. is in favor of IBK but I'm
> not
> > sure of his opinions on the other 2).
> >
> > I do wonder if we should consider having an interim in late May?
> I'm
> > not sure where we could hold it and how many people would be
> > interested, but I suspect it would help to make progress.
> >
> >
> > --
> > Wes Hardaker
> > Sparta, Inc.
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> >
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C53FD6.9AC440B3
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Informal consensus on dropping out of band =
keying?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Which IETF keying and security problems are being =
solved with encapsulation keying other than application transport =
protocols? I admit that I'm not up on all the latest protocols, but =
this seems counter to what I know.</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On</FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of David B Harrington</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 12, 2005 3:40 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Wes Hardaker'; 'Robert Story'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Isms] Informal consensus on =
dropping out of band keying?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I support the encapsulated approach, because =
that approach is</FONT>
<BR><FONT SIZE=3D2>&gt; consistent with how many other IETF keying and =
security problems are</FONT>
<BR><FONT SIZE=3D2>&gt; being resolved already, and we need to avoid =
reinventing the wheel for</FONT>
<BR><FONT SIZE=3D2>&gt; SNMP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I expect that in the future, the fact that =
there are many solutions</FONT>
<BR><FONT SIZE=3D2>&gt; now using or moving toward encapsulation for =
security will drive</FONT>
<BR><FONT SIZE=3D2>&gt; improved standardization of the security =
protocols involved, and SNMP</FONT>
<BR><FONT SIZE=3D2>&gt; should be ready to also converge on those =
standard solutions. I think</FONT>
<BR><FONT SIZE=3D2>&gt; an encapsulated approach should focus on =
utilizing IETF standardized</FONT>
<BR><FONT SIZE=3D2>&gt; layer 7 interfaces for encapsulated security =
and transport, such as</FONT>
<BR><FONT SIZE=3D2>&gt; SASL, BEEP, or SSH.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; For encapsulated; not much interested in the =
other architectures.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; dbh</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: isms-bounces@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Wes Hardaker</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, April 12, 2005 1:35 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Robert Story</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: [Isms] Informal consensus on =
dropping out of band</FONT>
<BR><FONT SIZE=3D2>&gt; keying?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&gt;&gt;&gt; On Tue, 12 Apr 2005 =
13:19:11 -0400, Robert Story</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;rstory@freesnmp.com&gt; said:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Robert&gt; We are just about half-way to =
our next dead-line, and I</FONT>
<BR><FONT SIZE=3D2>&gt; don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Robert&gt; get the sense that we are =
making much progress. If we could</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Robert&gt; narrow the discussion down to 2 =
architectures, instead of 3,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Robert&gt; that would be some =
progress.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Good summary, thanks.&nbsp; I suspected =
that's about where things lay.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; However, I think you must have missed at =
least a few opinions that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; might be discernible from comments =
(Juergen's S. for example I know</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; has posted a fair amount, though I don't =
remember which he agreed</FONT>
<BR><FONT SIZE=3D2>&gt; with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or disagreed with; I know that David P. is =
in favor of IBK but I'm</FONT>
<BR><FONT SIZE=3D2>&gt; not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sure of his opinions on the other =
2).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I do wonder if we should consider having =
an interim in late May?</FONT>
<BR><FONT SIZE=3D2>&gt; I'm</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; not sure where we could hold it and how =
many people would be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; interested, but I suspect it would help to =
make progress.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Wes Hardaker</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sparta, Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C53FD6.9AC440B3--


--===============1747471255==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1747471255==--



From isms-bounces@ietf.org  Tue Apr 12 23:26:22 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11758;
	Tue, 12 Apr 2005 23:26:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLYfz-0000wr-4D; Tue, 12 Apr 2005 23:36:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLYTu-0006Bm-PM; Tue, 12 Apr 2005 23:23:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLYTt-0006Bg-64
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 23:23:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11667
	for <isms@ietf.org>; Tue, 12 Apr 2005 23:23:54 -0400 (EDT)
Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLYda-0000uY-5G
	for isms@ietf.org; Tue, 12 Apr 2005 23:33:59 -0400
Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122]
	helo=oemcomputer)
	by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DLYTq-0001lb-00
	for isms@ietf.org; Tue, 12 Apr 2005 20:23:54 -0700
Message-ID: <002001c53fd8$6ac1d1a0$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9AF6@zcarhxm2.corp.nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 12 Apr 2005 20:25:18 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

Hi -

> From: "Martin Soukup" <msoukup@nortel.com>
> To: "'David T. Perkins'" <dperkins@dsperkins.com>; "Sharon Chisholm" <schishol@nortel.com>
> Cc: <isms@ietf.org>
> Sent: Tuesday, April 12, 2005 8:11 PM
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
>

> We would need to work through the effort involved in each implementation to
> judge which is more easily implementable, but I'm not sure that's possible
> at the abstract level of "should we use OOBK, IBK, or EBK". Are there any
...

I would think that using existing USM keying (whether you think of it as
OOBK or IBK) is the most easily implementable, since the infrastructure is
already in place at both ends.  The question is how to provide a mechanism
for key expiry on termination of a session.  One obvious solutions are an update
to the usm user entry using SNMPv3, the other is to AUGMENT the usm user
table with an expiration date / timer.  Alternatively one could use RFC 2786,
again augmenting the usm user table with a key expiry mechanism in order to
avoid changing the protocol by adding an explicit session termination.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Tue Apr 12 23:37:23 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12367;
	Tue, 12 Apr 2005 23:37:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLYqd-0001BY-Nw; Tue, 12 Apr 2005 23:47:28 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLYgL-0007rM-CO; Tue, 12 Apr 2005 23:36:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLYgK-0007qR-Hf
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 23:36:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12360
	for <isms@ietf.org>; Tue, 12 Apr 2005 23:36:21 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLYpe-0001BH-6i
	for isms@ietf.org; Tue, 12 Apr 2005 23:46:26 -0400
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3D3aCW23407; Tue, 12 Apr 2005 23:36:12 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j3D3aAO15767; Tue, 12 Apr 2005 23:36:10 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJBCF>; Tue, 12 Apr 2005 23:36:11 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9AFA@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Robert Story'" <rstory@freesnmp.com>, isms@ietf.org
Subject: RE: [Isms] Informal consensus on dropping out of band keying?
Date: Tue, 12 Apr 2005 23:35:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1511567179=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1511567179==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C53FD9.E7BCA943"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C53FD9.E7BCA943
Content-Type: text/plain

I have a definite preference for OOBK.
I would, unhappily, tolerate EK. If we go with EK, I'm not sure what the
advantages of using v3 really are though when running in an integrated
mode...

Reasons I significantly prefer OOBK (in order of importance):

1. There is no requirement for implicit trust of the session initiator of
the session provider. In OOBK the exchange of credentials is generally with
the AAA (when running in this mode and the AAA is available). This can be
dealt with by using independent key information from any centrally known
user credentials, but this is a pain, and not really an integrated approach.
2. OOBK is most reusable and in line with other management protocols IMO,
and is the most reusable (e.g. for netconf, OSS/J, WBEM - see Liberty and
SAML, Kerberos for non-IETF OOBK (where the K is an auth key)). IBK and EK
do not provide a decoupling of the security context from the communication
context which need to be decoupled since in an integrated security
infrastructure the communication context is separate from the security
context for good reason.
3. The OOBK is most modular and can be evolved in the field without impacts
to running devices.
4. OOBK has the most potential, IMO, of reuse of existing technologies
(other than perhaps some degenerate EK mechanisms)
5. OOBK is the only mechanism that doesn't modify the existing protocol
exchanges and is thus 100% backwards compatible
6. I believe that OOBK will provide much cheaper and operationally simple
integration with existing AAA systems

martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> Behalf Of Robert Story
> Sent: April 12, 2005 1:19 PM
> To: isms@ietf.org
> Subject: [Isms] Informal consensus on dropping out of band keying?
> 
> We are just about half-way to our next dead-line, and I don't get the
> sense
> that we are making much progress. If we could narrow the discussion down
> to 2
> architectures, instead of 3, that would be some progress.
> 
> Ken posted the three architectures for discussion on 3/18. Since then,
> there
> hasn't been too much discussion. I've summarized the preferences for
> people who
> have expressed one. If I mis-characterized your preference, please let me
> know.
> 
> 
> (OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate keying)
> 
> Wes Hardaker expressed a preference for IBK or EK.
> Kaushik Narayan expressed a preference for EK or IBK.
> Sharon Chisholm epxressed a preference for OOBK.
> Uri Blumenthal expressed a preference for IBK.
> Robert Story expressed a preference for IBK or EK.
> Ira McDonald expressed a preference for IBK (or at least not OOBK).
> 
> So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok, and
> 3
> also said EK would be ok.
> 
> If you haven't expressed a preference for one or two of the
> architectures, now would be a good time to do so.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C53FD9.E7BCA943
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Informal consensus on dropping out of band =
keying?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I have a definite preference for OOBK.</FONT>
<BR><FONT SIZE=3D2>I would, unhappily, tolerate EK. If we go with EK, =
I'm not sure what the advantages of using v3 really are though when =
running in an integrated mode...</FONT></P>

<P><FONT SIZE=3D2>Reasons I significantly prefer OOBK (in order of =
importance):</FONT>
</P>

<P><FONT SIZE=3D2>1. There is no requirement for implicit trust of the =
session initiator of the session provider. In OOBK the exchange of =
credentials is generally with the AAA (when running in this mode and =
the AAA is available). This can be dealt with by using independent key =
information from any centrally known user credentials, but this is a =
pain, and not really an integrated approach.</FONT></P>

<P><FONT SIZE=3D2>2. OOBK is most reusable and in line with other =
management protocols IMO, and is the most reusable (e.g. for netconf, =
OSS/J, WBEM - see Liberty and SAML, Kerberos for non-IETF OOBK (where =
the K is an auth key)). IBK and EK do not provide a decoupling of the =
security context from the communication context which need to be =
decoupled since in an integrated security infrastructure the =
communication context is separate from the security context for good =
reason.</FONT></P>

<P><FONT SIZE=3D2>3. The OOBK is most modular and can be evolved in the =
field without impacts to running devices.</FONT>
<BR><FONT SIZE=3D2>4. OOBK has the most potential, IMO, of reuse of =
existing technologies (other than perhaps some degenerate EK =
mechanisms)</FONT></P>

<P><FONT SIZE=3D2>5. OOBK is the only mechanism that doesn't modify the =
existing protocol exchanges and is thus 100% backwards =
compatible</FONT>
<BR><FONT SIZE=3D2>6. I believe that OOBK will provide much cheaper and =
operationally simple integration with existing AAA systems</FONT>
</P>

<P><FONT SIZE=3D2>martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On</FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of Robert Story</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 12, 2005 1:19 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [Isms] Informal consensus on dropping =
out of band keying?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We are just about half-way to our next =
dead-line, and I don't get the</FONT>
<BR><FONT SIZE=3D2>&gt; sense</FONT>
<BR><FONT SIZE=3D2>&gt; that we are making much progress. If we could =
narrow the discussion down</FONT>
<BR><FONT SIZE=3D2>&gt; to 2</FONT>
<BR><FONT SIZE=3D2>&gt; architectures, instead of 3, that would be some =
progress.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ken posted the three architectures for =
discussion on 3/18. Since then,</FONT>
<BR><FONT SIZE=3D2>&gt; there</FONT>
<BR><FONT SIZE=3D2>&gt; hasn't been too much discussion. I've =
summarized the preferences for</FONT>
<BR><FONT SIZE=3D2>&gt; people who</FONT>
<BR><FONT SIZE=3D2>&gt; have expressed one. If I mis-characterized your =
preference, please let me</FONT>
<BR><FONT SIZE=3D2>&gt; know.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (OOBK =3D Out of band keying, IBK =3D In band =
keying, EK =3D Encapsulate keying)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Wes Hardaker expressed a preference for IBK or =
EK.</FONT>
<BR><FONT SIZE=3D2>&gt; Kaushik Narayan expressed a preference for EK =
or IBK.</FONT>
<BR><FONT SIZE=3D2>&gt; Sharon Chisholm epxressed a preference for =
OOBK.</FONT>
<BR><FONT SIZE=3D2>&gt; Uri Blumenthal expressed a preference for =
IBK.</FONT>
<BR><FONT SIZE=3D2>&gt; Robert Story expressed a preference for IBK or =
EK.</FONT>
<BR><FONT SIZE=3D2>&gt; Ira McDonald expressed a preference for IBK (or =
at least not OOBK).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So of 6 opinions, only 1 was in favor of OOBK. =
5 said IBK would be ok, and</FONT>
<BR><FONT SIZE=3D2>&gt; 3</FONT>
<BR><FONT SIZE=3D2>&gt; also said EK would be ok.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you haven't expressed a preference for one =
or two of the</FONT>
<BR><FONT SIZE=3D2>&gt; architectures, now would be a good time to do =
so.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C53FD9.E7BCA943--


--===============1511567179==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1511567179==--



From isms-bounces@ietf.org  Wed Apr 13 00:47:12 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17726;
	Wed, 13 Apr 2005 00:47:12 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLZwD-00031S-Td; Wed, 13 Apr 2005 00:57:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLZkO-0003SM-2r; Wed, 13 Apr 2005 00:45:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLZkK-0003R6-J5
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 00:45:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17472
	for <isms@ietf.org>; Wed, 13 Apr 2005 00:44:55 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLZu0-0002wy-Fp
	for isms@ietf.org; Wed, 13 Apr 2005 00:55:01 -0400
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3D4ibw04082; Wed, 13 Apr 2005 00:44:38 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j3D4iam22994; Wed, 13 Apr 2005 00:44:36 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJBHG>; Wed, 13 Apr 2005 00:44:37 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B05@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>,
        "Sharon Chisholm" <schishol@nortel.com>, isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 00:44:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f0ea5880a0890be2408609376fa519aa
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2109900724=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: da41e01217ab11ad82db577473e913ae

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============2109900724==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C53FE3.256F9D69"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C53FE3.256F9D69
Content-Type: text/plain

Why isn't OOBK tied to a session lifetime? Why is one kind of key special
and gets a lifetime and the other doesn't? Is one not the favourite? I know
of some pretty good examples of OOBK's with lifetimes (e.g. things that use
X.509, a.k.a. EAP). Am I missing something?

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> Behalf Of Blumenthal, Uri
> Sent: April 5, 2005 12:03 PM
> To: Chisholm, Sharon [CAR:5K50:EXCH]; isms@ietf.org
> 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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
> On Behalf Of Sharon Chisholm
> Sent: Tuesday, April 05, 2005 10:33 AM
> To: isms@ietf.org
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> hi
> 
> Out of band keying is what is required.
> 
> Sharon
> 
> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
> On
> Behalf Of Ken Hornstein
> Sent: Friday, March 18, 2005 6:40 PM
> To: isms@ietf.org
> 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
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C53FE3.256F9D69
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Why isn't OOBK tied to a session lifetime? Why is one =
kind of key special and gets a lifetime and the other doesn't? Is one =
not the favourite? I know of some pretty good examples of OOBK's with =
lifetimes (e.g. things that use X.509, a.k.a. EAP). Am I missing =
something?</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On</FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of Blumenthal, Uri</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 5, 2005 12:03 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Chisholm, Sharon [CAR:5K50:EXCH]; =
isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; One problem with out-of-band keying is that it =
isn't tied with the</FONT>
<BR><FONT SIZE=3D2>&gt; session lifetime. It might be OK for one-time =
key setup, but less useful</FONT>
<BR><FONT SIZE=3D2>&gt; for routine access authorization.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Another problem is how to integrate it =
smoothly, and yet another one -</FONT>
<BR><FONT SIZE=3D2>&gt; [artificially] created need to maintain and =
synchronize two protocols</FONT>
<BR><FONT SIZE=3D2>&gt; and implementations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Summary: I'm a strong proponent of in-band =
keying.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; On Behalf Of Sharon Chisholm</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, April 05, 2005 10:33 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; hi</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Out of band keying is what is required.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; On</FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of Ken Hornstein</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, March 18, 2005 6:40 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Greetings all,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As you all know, the outcome from the ISMS =
working group meeting was</FONT>
<BR><FONT SIZE=3D2>&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; due to a number of events, we are now tasked =
with deciding on the</FONT>
<BR><FONT SIZE=3D2>&gt; architecture to use for ISMS.&nbsp; As =
discussed in the meeting, there are</FONT>
<BR><FONT SIZE=3D2>&gt; three</FONT>
<BR><FONT SIZE=3D2>&gt; obvious choices, which neatly correspond to the =
three proposed ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; protocols.&nbsp; Note that choosing a security =
architecture doesn't</FONT>
<BR><FONT SIZE=3D2>&gt; necessarily</FONT>
<BR><FONT SIZE=3D2>&gt; mean we have to choose the particular proposed =
protocol; my expectation</FONT>
<BR><FONT SIZE=3D2>&gt; is</FONT>
<BR><FONT SIZE=3D2>&gt; that once we pick a particular architecture, =
we'll develop a new</FONT>
<BR><FONT SIZE=3D2>&gt; protocol</FONT>
<BR><FONT SIZE=3D2>&gt; based on that architecture.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As I see it, we have the following =
architectures to choose from.&nbsp; Note</FONT>
<BR><FONT SIZE=3D2>&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; when I say &quot;features&quot;, I'm not making =
a decision on whether or not a</FONT>
<BR><FONT SIZE=3D2>&gt; feature</FONT>
<BR><FONT SIZE=3D2>&gt; is good or bad; it's just some of the more =
important points to consider.</FONT>
<BR><FONT SIZE=3D2>&gt; I</FONT>
<BR><FONT SIZE=3D2>&gt; have no doubt others will have other features =
to bring up about each</FONT>
<BR><FONT SIZE=3D2>&gt; architecture.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - &quot;Out of Band Keying&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; This is the approach chosen by =
EUSM.&nbsp; Essentially, a seperate protocol</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; exchange is conducted between the =
manager and agent (or a third party)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; and a key is then =
established/derived for use with standard USM.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Features:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Can make use of existing USM =
(already-analyzed protocol).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Likely wide variety of IETF =
protocols to use as out-of-band keying</FONT>
<BR><FONT SIZE=3D2>&gt; protocol</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Encryption/checksum modes limited =
to ones supported by USM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Extra care would be required to =
assure keying material derived from</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; out-of-band exchange is =
matched with a particular USM session.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - &quot;In Band Keying&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; This is the approach taken by =
SBSM.&nbsp; The security protocol is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; contained within SNMP payloads and =
likely whatever protocol is chosen</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; will have a way to secure the PDU =
contents.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Features:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Requires new SNMP security =
model.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Is more in line with the =
traditional way security is applied to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; application =
protocols.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Exact privacy/integrity details =
will need to be specified by this or</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; other protocol =
(depending on which framework is chosen).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - &quot;Encapsulation keying&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; This is the approach taken by =
TLSM.&nbsp; An encapsulation protocol (such</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; as TLS) is used to &quot;wrap&quot; =
SNMP payloads.&nbsp; A traditional USM could be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; run underneath this =
protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Likely requires no changes to =
SNMP protocol.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Is used by a number of other =
protocols with a great deal of success.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - _May_ require the use of =
TCP.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Traditional TLS only performs =
authentication for some mechanisms,</FONT>
<BR><FONT SIZE=3D2>&gt; may</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; require additional work =
to support other authentication schemes.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am sure that others will have additional =
features to add to the ones</FONT>
<BR><FONT SIZE=3D2>&gt; I've</FONT>
<BR><FONT SIZE=3D2>&gt; listed above.&nbsp; Anyway, please, anyone that =
has any thoughts, please lets</FONT>
<BR><FONT SIZE=3D2>&gt; get</FONT>
<BR><FONT SIZE=3D2>&gt; them out there!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --Ken</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C53FE3.256F9D69--


--===============2109900724==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============2109900724==--



From isms-bounces@ietf.org  Wed Apr 13 00:53:35 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17990;
	Wed, 13 Apr 2005 00:53:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLa2P-0003CO-GB; Wed, 13 Apr 2005 01:03:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLZqi-0004il-DQ; Wed, 13 Apr 2005 00:51:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPi3-0004dp-Bc
	for isms@megatron.ietf.org; Tue, 12 Apr 2005 14:01:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20620
	for <isms@ietf.org>; Tue, 12 Apr 2005 14:01:49 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPrX-0000Xa-72
	for isms@ietf.org; Tue, 12 Apr 2005 14:11:48 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3CI1W809120; Tue, 12 Apr 2005 14:01:32 -0400 (EDT)
Received: from nortelnetworks.com (wcary0w4.ca.nortel.com [47.129.148.152]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id 2NQARH2B; Tue, 12 Apr 2005 14:01:32 -0400
Message-ID: <425C0CFB.7090707@nortelnetworks.com>
Date: Tue, 12 Apr 2005 14:01:31 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Marcus Leech <mleech@nortelnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
References: <20050412131911.6b046d6d@aud>
In-Reply-To: <20050412131911.6b046d6d@aud>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 13 Apr 2005 00:51:31 -0400
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit

I'd be in favour of OOBK, because (it seems to me) this offers a relatively
  clean architecture, and the ability to make no-to-minimal changes to 
existing
  SNMPV3 stacks.

Robert Story wrote:

>We are just about half-way to our next dead-line, and I don't get the sense
>that we are making much progress. If we could narrow the discussion down to 2
>architectures, instead of 3, that would be some progress.
>
>Ken posted the three architectures for discussion on 3/18. Since then, there
>hasn't been too much discussion. I've summarized the preferences for people who
>have expressed one. If I mis-characterized your preference, please let me know.
>
>
>(OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate keying)
>
>Wes Hardaker expressed a preference for IBK or EK.
>Kaushik Narayan expressed a preference for EK or IBK.
>Sharon Chisholm epxressed a preference for OOBK.
>Uri Blumenthal expressed a preference for IBK.
>Robert Story expressed a preference for IBK or EK.
>Ira McDonald expressed a preference for IBK (or at least not OOBK).
>
>So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok, and 3
>also said EK would be ok.
>
>If you haven't expressed a preference for one or two of the
>architectures, now would be a good time to do so.
>
>_______________________________________________
>Isms mailing list
>Isms@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/isms
>
>
>  
>


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 01:15:09 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19236;
	Wed, 13 Apr 2005 01:15:09 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLaNF-0003eq-5z; Wed, 13 Apr 2005 01:25:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLaC4-0008I5-JF; Wed, 13 Apr 2005 01:13:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLaC2-0008Fi-TP
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 01:13:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19077
	for <isms@ietf.org>; Wed, 13 Apr 2005 01:13:38 -0400 (EDT)
Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLaLl-0003aN-JL
	for isms@ietf.org; Wed, 13 Apr 2005 01:23:41 -0400
Received: from h-64-105-137-68.snvacaid.dynamic.covad.net ([64.105.137.68]
	helo=oemcomputer)
	by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DLaB7-00035T-00
	for isms@ietf.org; Tue, 12 Apr 2005 22:12:41 -0700
Message-ID: <001e01c53fe7$9eedb160$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B05@zcarhxm2.corp.nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Tue, 12 Apr 2005 22:14:08 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

Hi -

> From: "Martin Soukup" <msoukup@nortel.com>
> To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>; "Sharon Chisholm" <schishol@nortel.com>; <isms@ietf.org>
> Sent: Tuesday, April 12, 2005 9:44 PM
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
>
> Why isn't OOBK tied to a session lifetime?
...

It could be. For example, if one used an OOBK mechanism in
conjuntion with snmpv3 USM, the mechanism could be
a set to the usm user table, or made automatic (to work with
"kidnapped" boxes) by augmenting the usm user table with
a key expiration date.

What's important is defining the sequence of interactions
so that the keys are delivered to the right places so the
useful communication can begin.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 01:43:48 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20909;
	Wed, 13 Apr 2005 01:43:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLaoy-0004F6-2w; Wed, 13 Apr 2005 01:53:52 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLaY9-00036N-TH; Wed, 13 Apr 2005 01:36:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLaY7-00035p-N9
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 01:36:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20533
	for <isms@ietf.org>; Wed, 13 Apr 2005 01:36:18 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLahh-00046Q-Sh
	for isms@ietf.org; Wed, 13 Apr 2005 01:46:22 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3D5a9ND013913; 
	Wed, 13 Apr 2005 05:36:09 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3D5a3pT008048; 
	Wed, 13 Apr 2005 05:36:09 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041222360831377 ; Tue, 12 Apr 2005 22:36:08 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 12 Apr 2005 22:36:09 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 12 Apr 2005 22:36:08 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 13 Apr 2005 01:36:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 01:35:46 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929F6A27E@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcU/2IO2XNM2qxNzTCW3vA0Sb1mVMgAEZJtw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>, <isms@ietf.org>
X-OriginalArrivalTime: 13 Apr 2005 05:36:07.0652 (UTC)
	FILETIME=[B1207A40:01C53FEA]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: quoted-printable

Yes using existing keying of USM is the most easily implementable. I
strongly favor AUGMENTing the usmUserTable with the relevant life-time
etc. attributes.

In addition to that IMHO we need the "establisher" logic and code. When
suitable USM entry isn't there yet (session hasn't been established), it
would perform its negotiation and successful result would be a properly
filled USM entry.

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Randy Presuhn
Sent: Tuesday, April 12, 2005 8:25 PM
To: isms@ietf.org
Subject: Re: [Isms] Discussion: Architecture direction for ISMS

Hi -

> From: "Martin Soukup" <msoukup@nortel.com>
> To: "'David T. Perkins'" <dperkins@dsperkins.com>; "Sharon Chisholm"
<schishol@nortel.com>
> Cc: <isms@ietf.org>
> Sent: Tuesday, April 12, 2005 8:11 PM
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
>

> We would need to work through the effort involved in each
implementation to
> judge which is more easily implementable, but I'm not sure that's
possible
> at the abstract level of "should we use OOBK, IBK, or EBK". Are there
any
...

I would think that using existing USM keying (whether you think of it as
OOBK or IBK) is the most easily implementable, since the infrastructure
is
already in place at both ends.  The question is how to provide a
mechanism
for key expiry on termination of a session.  One obvious solutions are
an update
to the usm user entry using SNMPv3, the other is to AUGMENT the usm user
table with an expiration date / timer.  Alternatively one could use RFC
2786,
again augmenting the usm user table with a key expiry mechanism in order
to
avoid changing the protocol by adding an explicit session termination.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 02:52:15 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00248;
	Wed, 13 Apr 2005 02:52:15 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLbtE-0005nq-Sw; Wed, 13 Apr 2005 03:02:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLbi0-0000J5-F9; Wed, 13 Apr 2005 02:50:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbhy-0000IE-EY
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 02:50:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00106
	for <isms@ietf.org>; Wed, 13 Apr 2005 02:50:40 -0400 (EDT)
Received: from i9403.i.pppool.de ([85.73.148.3] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLbrg-0005l8-O1
	for isms@ietf.org; Wed, 13 Apr 2005 03:00:46 -0400
Received: by boskop.local (Postfix, from userid 501)
	id 619B027C754; Wed, 13 Apr 2005 08:50:22 +0200 (CEST)
Date: Wed, 13 Apr 2005 08:50:21 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050413065021.GA29183@boskop.local>
Mail-Followup-To: "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	Randy Presuhn <randy_presuhn@mindspring.com>, isms@ietf.org
References: <3DEC199BD7489643817ECA151F7C5929F6A27E@pysmsx401.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929F6A27E@pysmsx401.amr.corp.intel.com>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 03:07:29 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01391;
	Wed, 13 Apr 2005 03:07:29 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLc7y-0006Ce-Kt; Wed, 13 Apr 2005 03:17:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLbvK-00030l-P1; Wed, 13 Apr 2005 03:04:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbv2-0002pb-1i
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 03:04:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01005
	for <isms@ietf.org>; Wed, 13 Apr 2005 03:04:02 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLc4d-00064Q-FK
	for isms@ietf.org; Wed, 13 Apr 2005 03:14:07 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3D73sw2019714; 
	Wed, 13 Apr 2005 07:03:54 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3D73rpV019329; 
	Wed, 13 Apr 2005 07:03:53 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041300035318438 ; Wed, 13 Apr 2005 00:03:53 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 13 Apr 2005 00:03:53 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 13 Apr 2005 00:03:52 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 13 Apr 2005 03:03:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 03:03:30 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929F6A285@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcU/9RjcqBxR0CJpQsqiSfYGwxcNOQAAAvlw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <j.schoenwaelder@iu-bremen.de>
X-OriginalArrivalTime: 13 Apr 2005 07:03:51.0648 (UTC)
	FILETIME=[F2B68600:01C53FF6]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: quoted-printable

>> 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.

Complex implementation to prove a point is even less of a goal.
Integration is about getting keying and authorization information from
already-deployed security infrastructure and mapping it onto VACM and
hopefully USM (because it's already there, and well-analyzed). If the
result allows [almost] direct hook-up to that existing infrastructure -
deployment's likely to be easy, and hopefully wide.

Though there's a decent chance that the complexity of SNMP-based
management issue will surface when the security excuse goes away.


>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=20
>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.

Mind you: I've been there.

It did not solve the problem at the end because the available tools were
very different.=20

I've tracked SNMP from v2 through its variations and to v3, so I'm
speaking from experience. I've stated my opinion. Others are entitled to
theirs.

>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=20
>of people who know IKE, SNMPv3/USM and such things. And I believe=20
>this is true in many enterprise networks.

1. TLS certs aren't any different from IKE certs, conceptually at least.
2. Your belief doesn't match market analysis that I'm seeing.

Regards,
Uri
<Disclaimer>

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 03:11:45 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01566;
	Wed, 13 Apr 2005 03:11:45 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLcC5-0006Ir-W3; Wed, 13 Apr 2005 03:21:51 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLbxJ-0003Rn-HK; Wed, 13 Apr 2005 03:06:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbxH-0003RR-Qu
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 03:06:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01344
	for <isms@ietf.org>; Wed, 13 Apr 2005 03:06:22 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLc6s-0006BV-O2
	for isms@ietf.org; Wed, 13 Apr 2005 03:16:28 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-5.cisco.com with ESMTP; 13 Apr 2005 00:06:14 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3D76AJd020470;
	Wed, 13 Apr 2005 00:06:11 -0700 (PDT)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp320.cisco.com [10.61.65.64])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3D6vbqx003047;
	Tue, 12 Apr 2005 23:57:38 -0700
Message-ID: <425CC4E0.60707@cisco.com>
Date: Wed, 13 Apr 2005 09:06:08 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil>	<Pine.LNX.4.10.10503181645290.429-100000@shell4.bayarea.net>	<20050321170043.39f3e05f@aud>
	<tsl1x9f924f.fsf@cz.mit.edu>
In-Reply-To: <tsl1x9f924f.fsf@cz.mit.edu>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113375459.424385"; x:"432200"; a:"rsa-sha1"; b:"nofws:1081";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"MbgqQWU7AEiynaA3wj743H3+G4eWwWobUCjZ2Lxi03ZCeA1+LRNeVJ+KMGfrr2n6eQTm6xS6"
	"BZzxux7cb+gIfLx0iLQEsGYEMNthhydBDwafC4raqXtA5bMmhtCu9iXt+xJT5/FuYxl7SY9/lR9"
	"bvm9UZlbmeAT7+uJgLwwtC0Y=";
	c:"Date: Wed, 13 Apr 2005 09:06:08 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: [Isms] Discussion: Architecture direction for ISMS"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit

Notification destinations are configured in advance, and so a TCP or 
SCTP connection in advance doesn't seem like a large price to pay.  In 
fact, you probably want to do this so that you can detect configuration 
errors BEFORE the notification is necessary.

Eliot


Sam Hartman wrote:
>>>>>>"Robert" == Robert Story <rstory@freesnmp.com> writes:
> 
> 
>     Robert> On Fri, 18 Mar 2005 17:26:22 -0800 (PST) David wrote:
>     DTP> On Fri, 18 Mar 2005, Ken Hornstein wrote: > - "Encapsulation
>     DTP> keying"
>     DTP> > 
>     DTP> > This is the approach taken by TLSM.  An encapsulation
>     DTP> protocol (such > as TLS) is used to "wrap" SNMP payloads.
> 
>     DTP> 2) Setting up sessions for delivering notifications.
> 
>     Robert> Speaking of notifications, isn't there an issue with the
>     Robert> transport approach and notifications? Doesn't net-conf
>     Robert> suffer from this issue? Specifically, sending a
>     Robert> notification when the notification destination doesn't
>     Robert> have an existing open session with the notification
>     Robert> generator.
> 
> Why is this true?  If all engines have credentials they can use, why can't you open a session if you need one?
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 07:54:21 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18102;
	Wed, 13 Apr 2005 07:54:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLgbb-0004hG-G1; Wed, 13 Apr 2005 08:04:28 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLgP6-00013J-1A; Wed, 13 Apr 2005 07:51:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgP4-000125-KU
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 07:51:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17922
	for <isms@ietf.org>; Wed, 13 Apr 2005 07:51:29 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLgYq-0004cj-57
	for isms@ietf.org; Wed, 13 Apr 2005 08:01:37 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50)
	id 1DLgP2-0001sU-Al; Wed, 13 Apr 2005 07:51:28 -0400
Date: Wed, 13 Apr 2005 07:52:26 -0400
From: Robert Story <rstory@freesnmp.com>
To: Eliot Lear <lear@cisco.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050413075226.1f14a945@aud>
In-Reply-To: <425CC4E0.60707@cisco.com>
References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil>
	<Pine.LNX.4.10.10503181645290.429-100000@shell4.bayarea.net>
	<20050321170043.39f3e05f@aud> <tsl1x9f924f.fsf@cz.mit.edu>
	<425CC4E0.60707@cisco.com>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit

On Wed, 13 Apr 2005 09:06:08 +0200 Eliot wrote:
EL> Notification destinations are configured in advance, and so a TCP or 
EL> SCTP connection in advance doesn't seem like a large price to pay.

It does if you are monitoring 100,000 devices. That's a lot of open connections
so that some (probably) relatively small number of devices can send
notifications.


EL> In fact, you probably want to do this so that you can detect configuration
EL> errors BEFORE the notification is necessary.

Setting up a temporary session to establish that a manager is there is a nice
optional feature that vendors could provide, but it certainly shouldn't be
required.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 07:57:39 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18323;
	Wed, 13 Apr 2005 07:57:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLgep-0004mH-6a; Wed, 13 Apr 2005 08:07:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLgUx-0002R6-Ec; Wed, 13 Apr 2005 07:57:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgUv-0002Pe-V9
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 07:57:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18287
	for <isms@ietf.org>; Wed, 13 Apr 2005 07:56:52 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLge4-0004lG-4Z
	for isms@ietf.org; Wed, 13 Apr 2005 08:07:00 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3DBufM09903; Wed, 13 Apr 2005 07:56:41 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3DBuhH08080; Wed, 13 Apr 2005 07:56:43 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJDXH>; Wed, 13 Apr 2005 07:56:40 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B0A@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'j.schoenwaelder@iu-bremen.de'" <j.schoenwaelder@iu-bremen.de>,
        "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 07:56:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1281027131=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1281027131==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5401F.D646E56B"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5401F.D646E56B
Content-Type: text/plain

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.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> Behalf Of Juergen Schoenwaelder
> Sent: April 13, 2005 2:50 AM
> To: Blumenthal, Uri
> Cc: isms@ietf.org
> 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
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C5401F.D646E56B
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

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

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5401F.D646E56B--


--===============1281027131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1281027131==--



From isms-bounces@ietf.org  Wed Apr 13 08:14:02 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19907;
	Wed, 13 Apr 2005 08:14:02 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLgug-0005Hc-GX; Wed, 13 Apr 2005 08:24:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLgkO-0004yL-PV; Wed, 13 Apr 2005 08:13:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgkN-0004xi-GN
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 08:13:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19887
	for <isms@ietf.org>; Wed, 13 Apr 2005 08:13:22 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLgu2-0005HD-9k
	for isms@ietf.org; Wed, 13 Apr 2005 08:23:30 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50)
	id 1DLgkE-0001y6-9O; Wed, 13 Apr 2005 08:13:22 -0400
Date: Wed, 13 Apr 2005 08:14:21 -0400
From: Robert Story <rstory@freesnmp.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050413081421.7ec8fa3a@aud>
In-Reply-To: <tsl1x9f924f.fsf@cz.mit.edu>
References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil>
	<Pine.LNX.4.10.10503181645290.429-100000@shell4.bayarea.net>
	<20050321170043.39f3e05f@aud> <tsl1x9f924f.fsf@cz.mit.edu>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit

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.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 08:29:18 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21242;
	Wed, 13 Apr 2005 08:29:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLh9S-0005jJ-Ey; Wed, 13 Apr 2005 08:39:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLgzW-0008Bq-1g; Wed, 13 Apr 2005 08:29:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgzU-0008BA-OM
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 08:29:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21221
	for <isms@ietf.org>; Wed, 13 Apr 2005 08:28:54 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLh94-0005iY-25
	for isms@ietf.org; Wed, 13 Apr 2005 08:39:02 -0400
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3DCSgf25784; Wed, 13 Apr 2005 08:28:43 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j3DCSQx02752; Wed, 13 Apr 2005 08:28:26 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJ1JT>; Wed, 13 Apr 2005 08:28:26 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B0D@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Robert Story'" <rstory@freesnmp.com>,
        Sam Hartman <hartmans-ietf@mit.edu>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 08:28:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1326750363=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1326750363==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54024.0F304477"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54024.0F304477
Content-Type: text/plain

Why does the reverse communication require any different configuration, or
are you just concerned because you have to configure both ends of the
communication (which we need to do anyways in USM)?

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story
> Sent: April 13, 2005 8:14 AM
> To: Sam Hartman
> Cc: isms@ietf.org
> 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 
> SH> can't 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.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

------_=_NextPart_001_01C54024.0F304477
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Why does the reverse communication require any =
different configuration, or are you just concerned because you have to =
configure both ends of the communication (which we need to do anyways =
in USM)?</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Robert Story</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 13, 2005 8:14 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Sam Hartman</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Tue, 12 Apr 2005 16:22:24 -0400 Sam =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; SH&gt; Why is this true?&nbsp; If all engines =
have credentials they </FONT>
<BR><FONT SIZE=3D2>&gt; can use, why </FONT>
<BR><FONT SIZE=3D2>&gt; SH&gt; can't you open a session if you need =
one?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My concern was was with regards to fitting into =
an existing </FONT>
<BR><FONT SIZE=3D2>&gt; infrastructure where unsolicited communication =
was not the </FONT>
<BR><FONT SIZE=3D2>&gt; norm. I use ssh as an example, because I am not =
familiar with </FONT>
<BR><FONT SIZE=3D2>&gt; TLS. While a ssh session does establish a key =
for the peer </FONT>
<BR><FONT SIZE=3D2>&gt; host, additional configuration would be needed =
to allow that </FONT>
<BR><FONT SIZE=3D2>&gt; peer to autonomously establish connections back =
to the </FONT>
<BR><FONT SIZE=3D2>&gt; originator's host.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; With one of the goals of ISMS being re-use of =
existing </FONT>
<BR><FONT SIZE=3D2>&gt; infrastructure, I was just thinking that for =
some </FONT>
<BR><FONT SIZE=3D2>&gt; infrastructures (eg ssh), get and set would =
easily fit, but </FONT>
<BR><FONT SIZE=3D2>&gt; notifications would require more =
thinking.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54024.0F304477--


--===============1326750363==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1326750363==--



From isms-bounces@ietf.org  Wed Apr 13 09:17:20 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24166;
	Wed, 13 Apr 2005 09:17:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLhtw-0006uu-Go; Wed, 13 Apr 2005 09:27:29 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLhjl-0008UI-Bu; Wed, 13 Apr 2005 09:16:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLhjk-0008Tg-H3
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 09:16:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24145
	for <isms@ietf.org>; Wed, 13 Apr 2005 09:16:47 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLhtO-0006uQ-Rn
	for isms@ietf.org; Wed, 13 Apr 2005 09:26:56 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50)
	id 1DLhjZ-0002Fy-Iw; Wed, 13 Apr 2005 09:16:45 -0400
Date: Wed, 13 Apr 2005 09:17:44 -0400
From: Robert Story <rstory@freesnmp.com>
To: "Martin Soukup" <msoukup@nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050413091744.4814dd63@aud>
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B0D@zcarhxm2.corp.nortel.com>
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B0D@zcarhxm2.corp.nortel.com>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit

On Wed, 13 Apr 2005 08:28:22 -0400 Martin wrote:
MS> Why does the reverse communication require any different 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.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 09:37:47 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25444;
	Wed, 13 Apr 2005 09:37:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLiDk-0007Ox-2V; Wed, 13 Apr 2005 09:47:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLhqS-0001lx-RH; Wed, 13 Apr 2005 09:23:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLhqR-0001lL-Kn
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 09:23:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24545
	for <isms@ietf.org>; Wed, 13 Apr 2005 09:23:42 -0400 (EDT)
Received: from romeo.rtfm.com ([198.144.203.242])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLi05-000766-Fw
	for isms@ietf.org; Wed, 13 Apr 2005 09:33:51 -0400
Received: by romeo.rtfm.com (Postfix, from userid 1001)
	id 4F8091705B; Wed, 13 Apr 2005 06:30:54 -0700 (PDT)
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B0D@zcarhxm2.corp.nortel.com>
	<20050413091744.4814dd63@aud>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 13 Apr 2005 06:30:54 -0700
In-Reply-To: <20050413091744.4814dd63@aud> (Robert Story's message of "Wed,
	13 Apr 2005 09:17:44 -0400")
Message-ID: <86mzs2u7ld.fsf@romeo.rtfm.com>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through
	Obscurity, berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@rtfm.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69

Robert Story <rstory@freesnmp.com> writes:

> On Wed, 13 Apr 2005 08:28:22 -0400 Martin wrote:
> MS> Why does the reverse communication require any different 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.

In SSL, at least, this problem has already been attacked in the
context of FTP, which involves callbacks on the data channel.
Basically, you do session resumption but the party that does
the active open (what one would think of as a TCP client)
acts as the SSL server. See draft-murray-auth-ftp-ssl-16.txt
(though the text isn't as clear as it could be).

Note that this assumes you want to tear down the TCP
connection. If you don't, then there's no problem, of course.
Incidentally, with DTLS you can just leave the DTLS association
up.

-Ekr



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 09:42:46 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25763;
	Wed, 13 Apr 2005 09:42:46 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLiIZ-0007W7-IZ; Wed, 13 Apr 2005 09:52:55 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLhsG-0001rp-CK; Wed, 13 Apr 2005 09:25:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLhsE-0001o5-FL
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 09:25:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24594
	for <isms@ietf.org>; Wed, 13 Apr 2005 09:24:44 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLi15-00077E-GV
	for isms@ietf.org; Wed, 13 Apr 2005 09:34:53 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3DDOW027262; Wed, 13 Apr 2005 09:24:32 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3DDOY220664; Wed, 13 Apr 2005 09:24:34 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJFYQ>; Wed, 13 Apr 2005 09:24:31 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B10@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Robert Story'" <rstory@freesnmp.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 09:24:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0262889618=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0262889618==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5402B.CFB27F29"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5402B.CFB27F29
Content-Type: text/plain

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.

> -----Original Message-----
> From: Robert Story [mailto:rstory@freesnmp.com] 
> Sent: April 13, 2005 9:18 AM
> To: Soukup, Martin [CAR:5K50:EXCH]
> Cc: isms@ietf.org
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> 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.
> 
> 

------_=_NextPart_001_01C5402B.CFB27F29
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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).</FONT></P>

<P><FONT SIZE=3D2>Point taken that the configuration has to happen on =
both ends, but you sort of have to do that anyways.</FONT>
</P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Robert Story [<A =
HREF=3D"mailto:rstory@freesnmp.com">mailto:rstory@freesnmp.com</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 13, 2005 9:18 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Soukup, Martin [CAR:5K50:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, 13 Apr 2005 08:28:22 -0400 Martin =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; MS&gt; Why does the reverse communication =
require any different </FONT>
<BR><FONT SIZE=3D2>&gt; MS&gt; configuration,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Again, I'm using the specific example of ssh in =
its current </FONT>
<BR><FONT SIZE=3D2>&gt; form. To communicate with a peer:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) generate my private/public keys</FONT>
<BR><FONT SIZE=3D2>&gt; 2) configure peer with my public key</FONT>
<BR><FONT SIZE=3D2>&gt; 3) connect to host (and peer host key is save =
for future reference)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is the existing infrastructure that I am =
referring to. </FONT>
<BR><FONT SIZE=3D2>&gt; Note that while I do have a key for the host, =
it is only used </FONT>
<BR><FONT SIZE=3D2>&gt; to verify that I'm talking to the same host the =
next time I connect.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To allow the host to connect back to my machine =
autonomously, </FONT>
<BR><FONT SIZE=3D2>&gt; I would have to:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4) generate a private/public key on the peer =
(possibly could </FONT>
<BR><FONT SIZE=3D2>&gt; re-use host key)</FONT>
<BR><FONT SIZE=3D2>&gt; 5) configure my host with the peer's public =
key</FONT>
<BR><FONT SIZE=3D2>&gt; 6) install/configure/run ssh server</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The point is that these steps are extra, and =
not part of the </FONT>
<BR><FONT SIZE=3D2>&gt; configuration of the existing =
infrastructure.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5402B.CFB27F29--


--===============0262889618==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0262889618==--



From isms-bounces@ietf.org  Wed Apr 13 09:47:06 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26042;
	Wed, 13 Apr 2005 09:47:06 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLiMk-0007c9-5e; Wed, 13 Apr 2005 09:57:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLi71-0002nF-Ki; Wed, 13 Apr 2005 09:40:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLi70-0002mp-8d
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 09:40:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25608
	for <isms@ietf.org>; Wed, 13 Apr 2005 09:40:48 -0400 (EDT)
Message-Id: <200504131340.JAA25608@ietf.org>
Received: from rwcrmhc13.comcast.net ([204.127.198.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLiGc-0007Sl-Lp
	for isms@ietf.org; Wed, 13 Apr 2005 09:50:57 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc13) with SMTP
	id <2005041313403701500h0cr8e>; Wed, 13 Apr 2005 13:40:37 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Robert Story'" <rstory@freesnmp.com>,
        "'Sam Hartman'" <hartmans-ietf@mit.edu>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 09:40:31 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <20050413081421.7ec8fa3a@aud>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVAIkfxd26N5XO8S4+V0gNQhwWAiQACGoTQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit

A GET-request is an unsolicited communication; only the response is
solicited. 

Netconf chose a model akin to SNMPv1's architecure, where one entity
is always the manager and the other is always the agent. The manager
is always allowed to initiate unsolicited communications to the agent.
It complicates the paradigm when it is necessary for the agent to send
an unsolicited message to the manager. 

The SNMPv3 architecture has been designed as an environment of peer
entities that happen to provide certain types of services. Both sides
of a relationship should be able to send unsolicited messages, e.g.
informs, if the two sides support the corresponding services. SNMPv3
allows a single entity to support  services to a)generate and
b)receive and c)respond to unsolicited communications. 

I think TLS fits the peer-to-peer approach. I agree that the SSH
architecture might be slightly more problematic establishing a two-way
relationship between peers.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story
> Sent: Wednesday, April 13, 2005 8:14 AM
> To: Sam Hartman
> Cc: isms@ietf.org
> 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.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 10:22:16 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00417;
	Wed, 13 Apr 2005 10:22:16 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLiun-0000AN-1N; Wed, 13 Apr 2005 10:32:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLihk-0001jq-HN; Wed, 13 Apr 2005 10:18:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLihi-0001it-5p
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 10:18:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29908
	for <isms@ietf.org>; Wed, 13 Apr 2005 10:18:44 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLirM-0008WB-Pd
	for isms@ietf.org; Wed, 13 Apr 2005 10:28:54 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-1.cisco.com with ESMTP; 13 Apr 2005 07:18:35 -0700
X-IronPort-AV: i="3.92,97,1112598000"; 
	d="scan'208"; a="628471927:sNHT32190512"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3DEIWJd004100;
	Wed, 13 Apr 2005 07:18:33 -0700 (PDT)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp4561.cisco.com [10.61.81.208])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3DE9xLd005412;
	Wed, 13 Apr 2005 07:09:59 -0700
Message-ID: <425D2A36.6030800@cisco.com>
Date: Wed, 13 Apr 2005 16:18:30 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil>	<Pine.LNX.4.10.10503181645290.429-100000@shell4.bayarea.net>	<20050321170043.39f3e05f@aud>	<tsl1x9f924f.fsf@cz.mit.edu>	<425CC4E0.60707@cisco.com>
	<20050413075226.1f14a945@aud>
In-Reply-To: <20050413075226.1f14a945@aud>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113401400.562545"; x:"432200"; a:"rsa-sha1"; b:"nofws:989";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"mZUrMjU5zODjyNfGpuPoFNQraTXKUkBJdd7P8h8DsOIAUvC5uWvZhloffl3ffYeb0W9GidzD"
	"XMPTIRNnRepqYH0qFqKJ1jBFngfsdqgth77R8g74UNku7W3JAoOsL3/YL7LxwBpxKOW3+YsPpWk"
	"e/lAitXsumRGa6F8xwwBCy84=";
	c:"Date: Wed, 13 Apr 2005 16:18:30 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: [Isms] Discussion: Architecture direction for ISMS"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit



Robert Story wrote:
> On Wed, 13 Apr 2005 09:06:08 +0200 Eliot wrote:
> EL> Notification destinations are configured in advance, and so a TCP or 
> EL> SCTP connection in advance doesn't seem like a large price to pay.
> 
> It does if you are monitoring 100,000 devices. That's a lot of open connections
> so that some (probably) relatively small number of devices can send
> notifications.

In the configuration you discuss, sure.  Would I in general advise such 
a configuration?  No.  For one thing, what if the trigger for the event 
is network-wide?  In that case you better be able to handle 100,000 
events on very short order.  Want to do that one one device?  YMMV.  I 
don't, however, want to engineer for an extreme corner case.

> 
> 
> EL> In fact, you probably want to do this so that you can detect configuration
> EL> errors BEFORE the notification is necessary.
> 
> Setting up a temporary session to establish that a manager is there is a nice
> optional feature that vendors could provide, but it certainly shouldn't be
> required.

Nothing stopping you from establishing a connection on demand.  Also 
nothing stopping someone from using existing UDP mechanisms.  It's not 
as if they're going away.

Eliot

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 12:23:48 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10818;
	Wed, 13 Apr 2005 12:23:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLkoR-0003dR-Kb; Wed, 13 Apr 2005 12:33:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLkdV-0005RV-9L; Wed, 13 Apr 2005 12:22:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkdT-0005KU-VD
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 12:22:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10720
	for <isms@ietf.org>; Wed, 13 Apr 2005 12:22:32 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLknC-0003ZU-2t
	for isms@ietf.org; Wed, 13 Apr 2005 12:32:43 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3DGMIw2011252; 
	Wed, 13 Apr 2005 16:22:18 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3DGMFpV031396; 
	Wed, 13 Apr 2005 16:22:15 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041309221514069 ; Wed, 13 Apr 2005 09:22:15 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 13 Apr 2005 09:22:15 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 13 Apr 2005 09:22:14 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 13 Apr 2005 12:22:12 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 12:21:49 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929F6A555@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVAIk8aIZ08LpRVRhi/Y8M/gMSo5gAIa2og
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Robert Story" <rstory@freesnmp.com>,
        "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 13 Apr 2005 16:22:12.0825 (UTC)
	FILETIME=[F2F87490:01C54044]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: quoted-printable

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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Robert Story
Sent: Wednesday, April 13, 2005 5:14 AM
To: Sam Hartman
Cc: isms@ietf.org
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.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 13:31:22 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16266;
	Wed, 13 Apr 2005 13:31:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLlrq-0005gs-QA; Wed, 13 Apr 2005 13:41:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLleo-0001eq-KM; Wed, 13 Apr 2005 13:28:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlen-0001e8-93
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 13:28:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16097
	for <isms@ietf.org>; Wed, 13 Apr 2005 13:27:38 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLloE-0005bk-Dc
	for isms@ietf.org; Wed, 13 Apr 2005 13:37:50 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3DHRVsC006514; 
	Wed, 13 Apr 2005 10:27:31 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3DHR0Rj006807;
	Wed, 13 Apr 2005 10:27:00 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3DHQxMD006792; Wed, 13 Apr 2005 10:27:00 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 13 Apr 2005 10:26:59 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Martin Soukup <msoukup@nortel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9AF6@zcarhxm2.corp.nortel.com>
Message-ID: <Pine.LNX.4.10.10504131023420.3991-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096

HI,

The word "implement" has different meanings. I can't tell
whether you mean the cost of designing, coding, testing, etc
to get the technology into products, or do you mean the cost
to deploy (initial install and on-going operations) products
containing the technology.

Would you clarify.

Thanks,
/david t. perkins

On Tue, 12 Apr 2005, Martin Soukup wrote:

> We would need to work through the effort involved in each implementation to
> judge which is more easily implementable, but I'm not sure that's possible
> at the abstract level of "should we use OOBK, IBK, or EBK". Are there any
> arguments that show there is a significant difference in implementation of
> these architectures that we can all agree on? I doubt it, since I think OOBK
> is the cheapest to implement and others on the list obviously differ in
> opinion. Would it be useful to break down what the major elements of
> implementation would be for each approach and lay them out for comparison?
> 
> Martin.
> 
> > -----Original Message-----
> > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> > Behalf Of David T. Perkins
> > Sent: April 12, 2005 4:32 PM
> > To: Chisholm, Sharon [CAR:5K50:EXCH]
> > Cc: isms@ietf.org
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> > 
> > HI,
> > 
> > Working code is a tradition in the IETF.
> > 
> > You haven't provided any costs and benefits
> > with using one architecture approach over
> > another.
> > 
> > What I'm suggesting is a validation of the
> > consequences of each approach. How would
> > you do this? I'm open to any approach that
> > addresses the problem of driving the
> > deployment (initial installation and
> > ongoing operational cost) of a secure
> > SNMP to a low enough number so that
> > it will be cost effective to use.
> > 
> > Please provide an actionable approach
> > that will provide some insights with
> > a reasonable amount of certainty.
> > 
> > Again....
> > > I've been doing some serious work on SNMPv3 for the last
> > > few months, and have had many meetings with the developers
> > > from the network management group, and with the security developers.
> > > SNMPv3 USM is quite difficult to understand, and email doesn't
> > > provide an effective medium for communication. Packet dumps,
> > > working code, multiple screens with the RFCs are tools that
> > > are needed to make progress.
> > 
> > Regards,
> > /david t. perkins
> > 
> > On Tue, 12 Apr 2005, Sharon Chisholm wrote:
> > > hi
> > >
> > > Somehow using a code inspection to determine the correct architecture
> > seems
> > > very wrong to me.
> > >
> > > Sharon
> > >
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > > Sent: Tuesday, April 05, 2005 3:49 PM
> > > To: Chisholm, Sharon [CAR:5K50:EXCH]
> > > Cc: isms@ietf.org
> > > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> > >
> > >
> > > HI,
> > >
> > > Lets set up a conference call to talk this through.
> > >
> > > Wes knows the internals of NET-SNMP. I've been going through the SNMP
> > > Research code. Hopefully we can get some other developers with knowledge
> > of
> > > other SNMP stacks together to work this out.
> > >
> > > And if any developers that are using the SNMP Research stack want to
> > talk to
> > > me about details, I'm open to setting up a private conversation. Send me
> > > email. (I cannot talk in detail about the code, since it is covered by a
> > > non-disclosure agreement, unless the other person is also covered by the
> > > non-disclosure agreement.)
> > >
> > > I would certainly appreciate talking with the SNMP developers at Nortel.
> > Let
> > > me know a time and a place, and I'll try to come visit for a day or two.
> > > Likewise, if anyone else wants to have a developer to developer talk,
> > please
> > > contact me.
> > >
> > > I've been doing some serious work on SNMPv3 for the last
> > > few months, and have had many meetings with the developers
> > > from the network management group, and with the security developers.
> > SNMPv3
> > > USM is quite difficult to understand, and email doesn't provide an
> > effective
> > > medium for communication. Packet dumps, working code, multiple screens
> > with
> > > the RFCs are tools that are needed to make progress.
> > >
> > > On Tue, 5 Apr 2005, Sharon Chisholm wrote:
> > > > <Wes>
> > > >
> > > > As do I.  Specifically, I think Robert's ordering of requirements
> > > > matches mine.  In-band first, and encapsulated being a second choice.
> > > > As I've mentioned in multiple other messages, there are a large number
> > > > of issues with out-of-band keying that makes implementation difficult.
> > > > I suspect Sharon must not agree with any of those other points? </Wes>
> > > >
> > > > No, not really. After our discussion in Minneapolis where you
> > > > mentioned the fact that you felt separate key management would be
> > > > impossible to implement in net-snmp, I went back and talked to some
> > > > more SNMPv3 implementers to get their view of implementing eUSM and
> > > > although they observed there were some missing elements of procedure,
> > > > they saw nothing that they felt would cause implementation problems.
> > > >
> > > > I'm a big fan of modular architectures. It allows you to add
> > > > functionality as you need it and to ensures a good return in
> > > > investment when looking to add new features. Yes, there are points
> > > > where having too many separate modules to worry about starts to cost
> > > > more than it saves and then you look at combining things together to
> > > > get some improvements. I don't think we are there in this particular
> > > > case.
> > > >
> > > > Sharon
> > >
> > > Regards,
> > > /david t. perkins
> > >
> > >
> > >
> > > _______________________________________________
> > > Isms mailing list
> > > Isms@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/isms
> > >
> > 
> > 
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> 
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 13:35:59 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16693;
	Wed, 13 Apr 2005 13:35:59 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLlwJ-0005pW-Vb; Wed, 13 Apr 2005 13:46:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLlm0-0002LO-1p; Wed, 13 Apr 2005 13:35:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLllz-0002Kv-Bq
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 13:35:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16647
	for <isms@ietf.org>; Wed, 13 Apr 2005 13:35:20 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlvg-0005nX-Pe
	for isms@ietf.org; Wed, 13 Apr 2005 13:45:33 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3DHZEsC008630; 
	Wed, 13 Apr 2005 10:35:14 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3DHYiT3009199;
	Wed, 13 Apr 2005 10:34:44 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3DHYiwe009195; Wed, 13 Apr 2005 10:34:44 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 13 Apr 2005 10:34:44 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Randy Presuhn <randy_presuhn@mindspring.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <002001c53fd8$6ac1d1a0$7f1afea9@oemcomputer>
Message-ID: <Pine.LNX.4.10.10504131028190.3991-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

HI,

My observation, and assumption is that the SNMP MIB objects
defined in the 3rd SNMP framework for configuration (especially
for user identity) are not being used. Thus, I see little
motivation to "save" them. 

In the systems that I recently reviewed, and the system that
I'm finishing up for delivery, NONE of the SNMP administrative
MIB objects for configuration are being made available.
There are many reasons.

This may be a world changing view. Ultimately the markets will
decide. And so far, there have little call by the markets
for SNMPv3 administration via SNMPv3.

Regards,
/david t. perkins

On Tue, 12 Apr 2005, Randy Presuhn wrote:

> Hi -
> 
> > From: "Martin Soukup" <msoukup@nortel.com>
> > To: "'David T. Perkins'" <dperkins@dsperkins.com>; "Sharon Chisholm" <schishol@nortel.com>
> > Cc: <isms@ietf.org>
> > Sent: Tuesday, April 12, 2005 8:11 PM
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> >
> 
> > We would need to work through the effort involved in each implementation to
> > judge which is more easily implementable, but I'm not sure that's possible
> > at the abstract level of "should we use OOBK, IBK, or EBK". Are there any
> ...
> 
> I would think that using existing USM keying (whether you think of it as
> OOBK or IBK) is the most easily implementable, since the infrastructure is
> already in place at both ends.  The question is how to provide a mechanism
> for key expiry on termination of a session.  One obvious solutions are an update
> to the usm user entry using SNMPv3, the other is to AUGMENT the usm user
> table with an expiration date / timer.  Alternatively one could use RFC 2786,
> again augmenting the usm user table with a key expiry mechanism in order to
> avoid changing the protocol by adding an explicit session termination.
> 
> Randy
> 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 13:48:57 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17616;
	Wed, 13 Apr 2005 13:48:57 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLm8q-0006AU-57; Wed, 13 Apr 2005 13:59:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLlxp-0004U6-Jz; Wed, 13 Apr 2005 13:47:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlxo-0004Th-9Y
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 13:47:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17521
	for <isms@ietf.org>; Wed, 13 Apr 2005 13:47:35 -0400 (EDT)
Received: from ib4e2.i.pppool.de ([85.73.180.226] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLm7U-000689-IN
	for isms@ietf.org; Wed, 13 Apr 2005 13:57:46 -0400
Received: by boskop.local (Postfix, from userid 501)
	id E22CC27C7FA; Wed, 13 Apr 2005 10:24:14 +0200 (CEST)
Date: Wed, 13 Apr 2005 10:24:14 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050413082414.GA29376@boskop.local>
Mail-Followup-To: "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	Randy Presuhn <randy_presuhn@mindspring.com>, isms@ietf.org
References: <3DEC199BD7489643817ECA151F7C5929F6A285@pysmsx401.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929F6A285@pysmsx401.amr.corp.intel.com>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

On Wed, Apr 13, 2005 at 03:03:30AM -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.
> 
> Complex implementation to prove a point is even less of a goal.

You are missing the point. Nobody said complex implementation is a goal.

> Integration is about getting keying and authorization information from
> already-deployed security infrastructure and mapping it onto VACM and
> hopefully USM (because it's already there, and well-analyzed). If the
> result allows [almost] direct hook-up to that existing infrastructure -
> deployment's likely to be easy, and hopefully wide.

At the end, someone needs to understand and debug things. If the 
machinery for oobk is getting increasingly complex, the need for 
this sort of debugging will grow in heterogenous environments. 

> I've tracked SNMP from v2 through its variations and to v3, so I'm
> speaking from experience. I've stated my opinion. Others are entitled to
> theirs.

Seems like we share some history but draw different lessons from 
the shared history.
 
> >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.
> 
> 1. TLS certs aren't any different from IKE certs, conceptually at least.

Conceptually the same and knowing the tools to get certs created, signed
and so on does make a difference. Using SNMPv3/USM is also conceptually
simple. But people are simply not willing to do extra work in order to
get secure SNMP. Either SNMP security comes almost for free for the 
operator (means integrates out of the box with other device access 
methods (CLIs, Web Server, netconf, ...) or people will not use it.

> 2. Your belief doesn't match market analysis that I'm seeing.

Conclusion: Lets simply disagree on the lessons learned from the history
and disagree on the properties of the target environments we have in mind.

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 15:11:38 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24564;
	Wed, 13 Apr 2005 15:11:38 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLnQs-0008QU-HH; Wed, 13 Apr 2005 15:21:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLnGf-00023k-PH; Wed, 13 Apr 2005 15:11:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLnGd-00023X-SU
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 15:11:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24506
	for <isms@ietf.org>; Wed, 13 Apr 2005 15:11:06 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLnQM-0008OK-36
	for isms@ietf.org; Wed, 13 Apr 2005 15:21:18 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3DJAqsC010907; 
	Wed, 13 Apr 2005 12:10:52 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3DJ8itT004676;
	Wed, 13 Apr 2005 12:08:44 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3DJ8h0l004673; Wed, 13 Apr 2005 12:08:44 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 13 Apr 2005 12:08:43 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: David B Harrington <ietfdbh@comcast.net>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <200504131340.JAA25608@ietf.org>
Message-ID: <Pine.LNX.4.10.10504131205460.3991-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: "'Sam Hartman'" <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8

HI,

I disagree with your characterization of SNMPv3. SNMP engines
do not have authenticated identifies. 

I'll explain further in another message.

/david t. perkins

On Wed, 13 Apr 2005, David B Harrington wrote:

> A GET-request is an unsolicited communication; only the response is
> solicited. 
> 
> Netconf chose a model akin to SNMPv1's architecure, where one entity
> is always the manager and the other is always the agent. The manager
> is always allowed to initiate unsolicited communications to the agent.
> It complicates the paradigm when it is necessary for the agent to send
> an unsolicited message to the manager. 
> 
> The SNMPv3 architecture has been designed as an environment of peer
> entities that happen to provide certain types of services. Both sides
> of a relationship should be able to send unsolicited messages, e.g.
> informs, if the two sides support the corresponding services. SNMPv3
> allows a single entity to support  services to a)generate and
> b)receive and c)respond to unsolicited communications. 
> 
> I think TLS fits the peer-to-peer approach. I agree that the SSH
> architecture might be slightly more problematic establishing a two-way
> relationship between peers.
> 
> David Harrington
> dbharrington@comcast.net
> 
> > -----Original Message-----
> > From: isms-bounces@lists.ietf.org 
> > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story
> > Sent: Wednesday, April 13, 2005 8:14 AM
> > To: Sam Hartman
> > Cc: isms@ietf.org
> > 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.
> > 
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 16:27:48 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03707;
	Wed, 13 Apr 2005 16:27:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLoca-0003DS-W4; Wed, 13 Apr 2005 16:38:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLoLO-00023D-CY; Wed, 13 Apr 2005 16:20:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLoLM-00022n-DB
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 16:20:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01586
	for <isms@ietf.org>; Wed, 13 Apr 2005 16:20:10 -0400 (EDT)
Message-Id: <200504132020.QAA01586@ietf.org>
Received: from rwcrmhc11.comcast.net ([204.127.198.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLoV9-0002Sj-VY
	for isms@ietf.org; Wed, 13 Apr 2005 16:30:23 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc11) with SMTP
	id <2005041320195801300knpole>; Wed, 13 Apr 2005 20:19:59 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'David T. Perkins'" <dperkins@dsperkins.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 16:19:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <Pine.LNX.4.10.10504131205460.3991-100000@shell4.bayarea.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVAXIJ48rleBVh3T+qMoROq8pp2jAACUapw
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: 7bit
Cc: "'Sam Hartman'" <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Content-Transfer-Encoding: 7bit

Hi David,

When you decide to post your explanation, please indictae where in my
message you think I characterized SNMPv3 as having engines with
authenticated identities. I have read and reread what I said, and I
don't see that I ever said that.

dbh

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> Sent: Wednesday, April 13, 2005 3:09 PM
> To: David B Harrington
> Cc: 'Robert Story'; 'Sam Hartman'; isms@ietf.org
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> HI,
> 
> I disagree with your characterization of SNMPv3. SNMP engines
> do not have authenticated identifies. 
> 
> I'll explain further in another message.
> 
> /david t. perkins
> 
> On Wed, 13 Apr 2005, David B Harrington wrote:
> 
> > A GET-request is an unsolicited communication; only the response
is
> > solicited. 
> > 
> > Netconf chose a model akin to SNMPv1's architecure, where one
entity
> > is always the manager and the other is always the agent. The
manager
> > is always allowed to initiate unsolicited communications to 
> the agent.
> > It complicates the paradigm when it is necessary for the 
> agent to send
> > an unsolicited message to the manager. 
> > 
> > The SNMPv3 architecture has been designed as an environment of
peer
> > entities that happen to provide certain types of services. 
> Both sides
> > of a relationship should be able to send unsolicited messages,
e.g.
> > informs, if the two sides support the corresponding services.
SNMPv3
> > allows a single entity to support  services to a)generate and
> > b)receive and c)respond to unsolicited communications. 
> > 
> > I think TLS fits the peer-to-peer approach. I agree that the SSH
> > architecture might be slightly more problematic 
> establishing a two-way
> > relationship between peers.
> > 
> > David Harrington
> > dbharrington@comcast.net
> > 
> > > -----Original Message-----
> > > From: isms-bounces@lists.ietf.org 
> > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story
> > > Sent: Wednesday, April 13, 2005 8:14 AM
> > > To: Sam Hartman
> > > Cc: isms@ietf.org
> > > 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.
> > > 
> > > _______________________________________________
> > > Isms mailing list
> > > Isms@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/isms
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> 
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 16:41:35 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05751;
	Wed, 13 Apr 2005 16:41:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLopv-0003sX-Nh; Wed, 13 Apr 2005 16:51:49 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLoey-0001JK-NM; Wed, 13 Apr 2005 16:40:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLoew-0001Gh-Pd
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 16:40:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05638
	for <isms@ietf.org>; Wed, 13 Apr 2005 16:40:16 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLooe-0003pK-Nf
	for isms@ietf.org; Wed, 13 Apr 2005 16:50:30 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3DKdosC016304; 
	Wed, 13 Apr 2005 13:39:50 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3DKbfUQ030770;
	Wed, 13 Apr 2005 13:37:42 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3DKbfRM030761; Wed, 13 Apr 2005 13:37:41 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 13 Apr 2005 13:37:40 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: David B Harrington <ietfdbh@comcast.net>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <200504132020.j3DKJxTi011117@mx1.bayarea.net>
Message-ID: <Pine.LNX.4.10.10504131322140.23768-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: "'Sam Hartman'" <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b

HI,

I thought you were using the term "peer entity" to
mean an SNMP engine. I'm sorry that I misinterpreted
that if you meant something else. What do you mean
by "peer entity"? What identity is used for each peer?

Regards,
/david t. perkins
On Wed, 13 Apr 2005, David B Harrington wrote:

> Hi David,
> 
> When you decide to post your explanation, please indictae where in my
> message you think I characterized SNMPv3 as having engines with
> authenticated identities. I have read and reread what I said, and I
> don't see that I ever said that.
> 
> dbh
> 
> > -----Original Message-----
> > From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> > Sent: Wednesday, April 13, 2005 3:09 PM
> > To: David B Harrington
> > Cc: 'Robert Story'; 'Sam Hartman'; isms@ietf.org
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> > 
> > HI,
> > 
> > I disagree with your characterization of SNMPv3. SNMP engines
> > do not have authenticated identifies. 
> > 
> > I'll explain further in another message.
> > 
> > /david t. perkins
> > 
> > On Wed, 13 Apr 2005, David B Harrington wrote:
> > 
> > > A GET-request is an unsolicited communication; only the response
> is
> > > solicited. 
> > > 
> > > Netconf chose a model akin to SNMPv1's architecure, where one
> entity
> > > is always the manager and the other is always the agent. The
> manager
> > > is always allowed to initiate unsolicited communications to 
> > the agent.
> > > It complicates the paradigm when it is necessary for the 
> > agent to send
> > > an unsolicited message to the manager. 
> > > 
> > > The SNMPv3 architecture has been designed as an environment of
> peer
> > > entities that happen to provide certain types of services. 
> > Both sides
> > > of a relationship should be able to send unsolicited messages,
> e.g.
> > > informs, if the two sides support the corresponding services.
> SNMPv3
> > > allows a single entity to support  services to a)generate and
> > > b)receive and c)respond to unsolicited communications. 
> > > 
> > > I think TLS fits the peer-to-peer approach. I agree that the SSH
> > > architecture might be slightly more problematic 
> > establishing a two-way
> > > relationship between peers.
> > > 
> > > David Harrington
> > > dbharrington@comcast.net
> > > 
> > > > -----Original Message-----
> > > > From: isms-bounces@lists.ietf.org 
> > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story
> > > > Sent: Wednesday, April 13, 2005 8:14 AM
> > > > To: Sam Hartman
> > > > Cc: isms@ietf.org
> > > > 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.
> > > > 
> > > > _______________________________________________
> > > > Isms mailing list
> > > > Isms@lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/isms
> > > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Isms mailing list
> > > Isms@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/isms
> > > 
> > 
> > 
> 
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 20:56:17 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24842;
	Wed, 13 Apr 2005 20:56:17 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLsoS-0001nb-OK; Wed, 13 Apr 2005 21:06:32 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLsbE-0005MS-J7; Wed, 13 Apr 2005 20:52:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsbC-0005Ke-Rx
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 20:52:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24600
	for <isms@ietf.org>; Wed, 13 Apr 2005 20:52:41 -0400 (EDT)
Received: from stratton-two.mit.edu ([18.187.5.2]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLskx-0001fz-9q
	for isms@ietf.org; Wed, 13 Apr 2005 21:02:56 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 592FDE0063; Wed, 13 Apr 2005 20:52:03 -0400 (EDT)
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil>
	<Pine.LNX.4.10.10503181645290.429-100000@shell4.bayarea.net>
	<20050321170043.39f3e05f@aud> <tsl1x9f924f.fsf@cz.mit.edu>
	<20050413081421.7ec8fa3a@aud>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Wed, 13 Apr 2005 20:52:03 -0400
In-Reply-To: <20050413081421.7ec8fa3a@aud> (Robert Story's message of "Wed,
	13 Apr 2005 08:14:21 -0400")
Message-ID: <tslaco2kwng.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

>>>>> "Robert" == Robert Story <rstory@freesnmp.com> writes:

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

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

Why do you need to use the same key.  SNMP is symmetric; have two
sessions one from a to be and one from b to a.  The only requirement
is that both a and b have credentials.


That's often true for ssh if you have both a server and client
implementation available.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 20:57:42 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24943;
	Wed, 13 Apr 2005 20:57:42 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLspp-0001pG-2b; Wed, 13 Apr 2005 21:07:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLsfi-00060V-NZ; Wed, 13 Apr 2005 20:57:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsfg-0005xC-Oi
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 20:57:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24918
	for <isms@ietf.org>; Wed, 13 Apr 2005 20:57:27 -0400 (EDT)
Received: from stratton-two.mit.edu ([18.187.5.2]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLspa-0001p2-8j
	for isms@ietf.org; Wed, 13 Apr 2005 21:07:42 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id C40EAE0063; Wed, 13 Apr 2005 20:57:26 -0400 (EDT)
To: "David T. Perkins" <dperkins@dsperkins.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <Pine.LNX.4.10.10504131205460.3991-100000@shell4.bayarea.net>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Wed, 13 Apr 2005 20:57:26 -0400
In-Reply-To: <Pine.LNX.4.10.10504131205460.3991-100000@shell4.bayarea.net>
	(David
	T. Perkins's message of "Wed, 13 Apr 2005 12:08:43 -0700 (PDT)")
Message-ID: <tsl3btukweh.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

>>>>> "David" == David T Perkins <dperkins@dsperkins.com> writes:

    David> HI, I disagree with your characterization of SNMPv3. SNMP
    David> engines do not have authenticated identifies.

    David> I'll explain further in another message.

As I understand it, I think we're trying to allow SNMP engines to
communicate securely using existing credentials in an existing
infrastructure.  Please correct me if this understanding is wrong; it
is fairly fundamental to my thinking in this WG.

As such, by the time we're done, it seems reasonable to expect that
SNMP engines using ISMS w will clearly know what set of credentials
they are using.  Associated with all the IETF security credentials I'm
familiar with is an authenticated identity.  Sometimes this identity
is implicit or tautological (for example the identity of a raw public
key is often that key), but it does exist.

--Sam


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 21:13:51 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26272;
	Wed, 13 Apr 2005 21:13:51 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLt5S-0002F6-US; Wed, 13 Apr 2005 21:24:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLst3-00087G-1q; Wed, 13 Apr 2005 21:11:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLst2-00087B-H6
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 21:11:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25922
	for <isms@ietf.org>; Wed, 13 Apr 2005 21:11:14 -0400 (EDT)
Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLt2v-00028Z-2b
	for isms@ietf.org; Wed, 13 Apr 2005 21:21:30 -0400
Received: from h-68-166-189-41.snvacaid.dynamic.covad.net ([68.166.189.41]
	helo=oemcomputer)
	by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DLssz-0007fI-00
	for isms@ietf.org; Wed, 13 Apr 2005 18:11:13 -0700
Message-ID: <002001c5408f$0efba140$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <Pine.LNX.4.10.10504131205460.3991-100000@shell4.bayarea.net>
	<tsl3btukweh.fsf@cz.mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 18:12:42 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 2.9 (++)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 2.9 (++)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

Hi -

> From: "Sam Hartman" <hartmans-ietf@mit.edu>
> To: "David T. Perkins" <dperkins@dsperkins.com>
> Cc: <isms@ietf.org>
> Sent: Wednesday, April 13, 2005 5:57 PM
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
...
> As I understand it, I think we're trying to allow SNMP engines to
> communicate securely using existing credentials in an existing
> infrastructure.  Please correct me if this understanding is wrong; it
> is fairly fundamental to my thinking in this WG.

The communication is between SNMP applications on behalf of users.
The SNMP engine is just the machine that does the work on their behalf.

> As such, by the time we're done, it seems reasonable to expect that
> SNMP engines using ISMS w will clearly know what set of credentials
> they are using.  Associated with all the IETF security credentials I'm
> familiar with is an authenticated identity.  Sometimes this identity
> is implicit or tautological (for example the identity of a raw public
> key is often that key), but it does exist.

Those credentials are (at least in USM) those of the users, not of the
engines per se.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Wed Apr 13 21:54:19 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28484;
	Wed, 13 Apr 2005 21:54:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLtic-0003GY-GS; Wed, 13 Apr 2005 22:04:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLtXr-00067A-VE; Wed, 13 Apr 2005 21:53:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtXq-000674-Rc
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 21:53:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28442
	for <isms@ietf.org>; Wed, 13 Apr 2005 21:53:24 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLthk-0003Ed-Fp
	for isms@ietf.org; Wed, 13 Apr 2005 22:03:41 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3E1r6820066; Wed, 13 Apr 2005 21:53:06 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3E1r8719157; Wed, 13 Apr 2005 21:53:08 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RJV1Y>; Wed, 13 Apr 2005 21:53:05 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'j.schoenwaelder@iu-bremen.de'" <j.schoenwaelder@iu-bremen.de>,
        "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 21:52:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1973541916=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1973541916==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54094.486E6D4D"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54094.486E6D4D
Content-Type: text/plain



> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen 
> Schoenwaelder
> Sent: April 13, 2005 4:24 AM
> To: Blumenthal, Uri
> Cc: isms@ietf.org
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> On Wed, Apr 13, 2005 at 03:03:30AM -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.
> > 
> > Complex implementation to prove a point is even less of a goal.
> 
> You are missing the point. Nobody said complex implementation 
> is a goal.
> 
> > Integration is about getting keying and authorization 
> information from 
> > already-deployed security infrastructure and mapping it 
> onto VACM and 
> > hopefully USM (because it's already there, and 
> well-analyzed). If the 
> > result allows [almost] direct hook-up to that existing 
> infrastructure 
> > - deployment's likely to be easy, and hopefully wide.
> 
> At the end, someone needs to understand and debug things. If the 
> machinery for oobk is getting increasingly complex, the need for 
> this sort of debugging will grow in heterogenous environments. 

It is true that we need to reduce complexity, that is why I like OOBK. The
modularity provides a separation of concerns which is easier to debug and
test. 

> > I've tracked SNMP from v2 through its variations and to v3, so I'm 
> > speaking from experience. I've stated my opinion. Others 
> are entitled 
> > to theirs.
> 
> Seems like we share some history but draw different lessons from 
> the shared history.
>  
> > >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.
> > 
> > 1. TLS certs aren't any different from IKE certs, conceptually at 
> > least.
> 
> Conceptually the same and knowing the tools to get certs 
> created, signed and so on does make a difference. Using 
> SNMPv3/USM is also conceptually simple. But people are simply 
> not willing to do extra work in order to get secure SNMP. 
> Either SNMP security comes almost for free for the 
> operator (means integrates out of the box with other device access 
> methods (CLIs, Web Server, netconf, ...) or people will not use it.
> 
> > 2. Your belief doesn't match market analysis that I'm seeing.
> 
> Conclusion: Lets simply disagree on the lessons learned from 
> the history and disagree on the properties of the target 
> environments we have in mind.

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?

> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

------_=_NextPart_001_01C54094.486E6D4D
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Juergen </FONT>
<BR><FONT SIZE=3D2>&gt; Schoenwaelder</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 13, 2005 4:24 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Blumenthal, Uri</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, Apr 13, 2005 at 03:03:30AM -0400, =
Blumenthal, Uri wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Yes using existing keying of USM =
is the most easily </FONT>
<BR><FONT SIZE=3D2>&gt; implementable. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; I strongly favor AUGMENTing the =
usmUserTable with the relevant</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; life-time</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; etc. attributes.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Easy implementation is a nice feature =
but at the end can't be the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;goal of this WG. This WG is about =
integration and ultimately </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;deployment.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Complex implementation to prove a point is =
even less of a goal.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You are missing the point. Nobody said complex =
implementation </FONT>
<BR><FONT SIZE=3D2>&gt; is a goal.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Integration is about getting keying and =
authorization </FONT>
<BR><FONT SIZE=3D2>&gt; information from </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; already-deployed security infrastructure =
and mapping it </FONT>
<BR><FONT SIZE=3D2>&gt; onto VACM and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; hopefully USM (because it's already there, =
and </FONT>
<BR><FONT SIZE=3D2>&gt; well-analyzed). If the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; result allows [almost] direct hook-up to =
that existing </FONT>
<BR><FONT SIZE=3D2>&gt; infrastructure </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; - deployment's likely to be easy, and =
hopefully wide.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At the end, someone needs to understand and =
debug things. If the </FONT>
<BR><FONT SIZE=3D2>&gt; machinery for oobk is getting increasingly =
complex, the need for </FONT>
<BR><FONT SIZE=3D2>&gt; this sort of debugging will grow in =
heterogenous environments. </FONT>
</P>

<P><FONT SIZE=3D2>It is true that we need to reduce complexity, that is =
why I like OOBK. The modularity provides a separation of concerns which =
is easier to debug and test. </FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; I've tracked SNMP from v2 through its =
variations and to v3, so I'm </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; speaking from experience. I've stated my =
opinion. Others </FONT>
<BR><FONT SIZE=3D2>&gt; are entitled </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to theirs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Seems like we share some history but draw =
different lessons from </FONT>
<BR><FONT SIZE=3D2>&gt; the shared history.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;In my University, the number of people =
who know how to </FONT>
<BR><FONT SIZE=3D2>&gt; deal with TLS </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;certificates or SSH keys is much much =
bigger compared to </FONT>
<BR><FONT SIZE=3D2>&gt; the number </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;of people who know IKE, SNMPv3/USM and =
such things. And I believe </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;this is true in many enterprise =
networks.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1. TLS certs aren't any different from IKE =
certs, conceptually at </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; least.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Conceptually the same and knowing the tools to =
get certs </FONT>
<BR><FONT SIZE=3D2>&gt; created, signed and so on does make a =
difference. Using </FONT>
<BR><FONT SIZE=3D2>&gt; SNMPv3/USM is also conceptually simple. But =
people are simply </FONT>
<BR><FONT SIZE=3D2>&gt; not willing to do extra work in order to get =
secure SNMP. </FONT>
<BR><FONT SIZE=3D2>&gt; Either SNMP security comes almost for free for =
the </FONT>
<BR><FONT SIZE=3D2>&gt; operator (means integrates out of the box with =
other device access </FONT>
<BR><FONT SIZE=3D2>&gt; methods (CLIs, Web Server, netconf, ...) or =
people will not use it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2. Your belief doesn't match market =
analysis that I'm seeing.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Conclusion: Lets simply disagree on the lessons =
learned from </FONT>
<BR><FONT SIZE=3D2>&gt; the history and disagree on the properties of =
the target </FONT>
<BR><FONT SIZE=3D2>&gt; environments we have in mind.</FONT>
</P>

<P><FONT SIZE=3D2>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?</FONT></P>

<P><FONT SIZE=3D2>&gt; /js</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Juergen Schoenwaelder =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
International University Bremen</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A HREF=3D"http://www.eecs.iu-bremen.de/" =
TARGET=3D"_blank">http://www.eecs.iu-bremen.de/</A>&gt;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; P.O. Box 750 561, </FONT>
<BR><FONT SIZE=3D2>&gt; 28725 Bremen, Germany</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54094.486E6D4D--


--===============1973541916==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1973541916==--



From isms-bounces@ietf.org  Wed Apr 13 22:10:46 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29494;
	Wed, 13 Apr 2005 22:10:46 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DLtyY-0003e2-ME; Wed, 13 Apr 2005 22:21:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DLtnG-0008A8-IK; Wed, 13 Apr 2005 22:09:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtnF-000899-Or
	for isms@megatron.ietf.org; Wed, 13 Apr 2005 22:09:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29385
	for <isms@ietf.org>; Wed, 13 Apr 2005 22:09:19 -0400 (EDT)
Message-Id: <200504140209.WAA29385@ietf.org>
Received: from rwcrmhc11.comcast.net ([204.127.198.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLtx8-0003c0-DT
	for isms@ietf.org; Wed, 13 Apr 2005 22:19:36 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc11) with SMTP
	id <2005041402090901300ktet6e>; Thu, 14 Apr 2005 02:09:09 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'David T. Perkins'" <dperkins@dsperkins.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Wed, 13 Apr 2005 22:09:03 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <Pine.LNX.4.10.10504131322140.23768-100000@shell4.bayarea.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVAaPAqVsrjAFYuQQWqLXntfsch7AAJxVbQ
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Content-Transfer-Encoding: 7bit
Cc: "'Sam Hartman'" <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Content-Transfer-Encoding: 7bit

Hi David,

You are correct; I am using "peer entity" to refer to SNMP engines.
Dictionary.com defines "peer" as "A person who has equal standing with
another or others." I think that is a reasonable characterization of
the relationship between SNMPv3 engines, especially when compared to
the relationships of SNMPv1/v2 engines as manager/agent. 

I didn't say that SNMP engines have authenticated identities.

David Harrington
dbharrington@comcast.net


> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> Sent: Wednesday, April 13, 2005 4:38 PM
> To: David B Harrington
> Cc: 'Robert Story'; 'Sam Hartman'; isms@ietf.org
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> HI,
> 
> I thought you were using the term "peer entity" to
> mean an SNMP engine. I'm sorry that I misinterpreted
> that if you meant something else. What do you mean
> by "peer entity"? What identity is used for each peer?
> 
> Regards,
> /david t. perkins
> On Wed, 13 Apr 2005, David B Harrington wrote:
> 
> > Hi David,
> > 
> > When you decide to post your explanation, please indictae 
> where in my
> > message you think I characterized SNMPv3 as having engines with
> > authenticated identities. I have read and reread what I said, and
I
> > don't see that I ever said that.
> > 
> > dbh
> > 
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> > > Sent: Wednesday, April 13, 2005 3:09 PM
> > > To: David B Harrington
> > > Cc: 'Robert Story'; 'Sam Hartman'; isms@ietf.org
> > > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> > > 
> > > HI,
> > > 
> > > I disagree with your characterization of SNMPv3. SNMP engines
> > > do not have authenticated identifies. 
> > > 
> > > I'll explain further in another message.
> > > 
> > > /david t. perkins
> > > 
> > > On Wed, 13 Apr 2005, David B Harrington wrote:
> > > 
> > > > A GET-request is an unsolicited communication; only the
response
> > is
> > > > solicited. 
> > > > 
> > > > Netconf chose a model akin to SNMPv1's architecure, where one
> > entity
> > > > is always the manager and the other is always the agent. The
> > manager
> > > > is always allowed to initiate unsolicited communications to 
> > > the agent.
> > > > It complicates the paradigm when it is necessary for the 
> > > agent to send
> > > > an unsolicited message to the manager. 
> > > > 
> > > > The SNMPv3 architecture has been designed as an environment of
> > peer
> > > > entities that happen to provide certain types of services. 
> > > Both sides
> > > > of a relationship should be able to send unsolicited messages,
> > e.g.
> > > > informs, if the two sides support the corresponding services.
> > SNMPv3
> > > > allows a single entity to support  services to a)generate and
> > > > b)receive and c)respond to unsolicited communications. 
> > > > 
> > > > I think TLS fits the peer-to-peer approach. I agree that the
SSH
> > > > architecture might be slightly more problematic 
> > > establishing a two-way
> > > > relationship between peers.
> > > > 
> > > > David Harrington
> > > > dbharrington@comcast.net
> > > > 
> > > > > -----Original Message-----
> > > > > From: isms-bounces@lists.ietf.org 
> > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert
Story
> > > > > Sent: Wednesday, April 13, 2005 8:14 AM
> > > > > To: Sam Hartman
> > > > > Cc: isms@ietf.org
> > > > > 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.
> > > > > 
> > > > > _______________________________________________
> > > > > Isms mailing list
> > > > > Isms@lists.ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/isms
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Isms mailing list
> > > > Isms@lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/isms
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 12:37:02 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00079;
	Thu, 14 Apr 2005 12:37:02 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM7V0-0007Ih-WE; Thu, 14 Apr 2005 12:47:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM7K0-00083O-78; Thu, 14 Apr 2005 12:36:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7Jy-00082N-Qq
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 12:36:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29978
	for <isms@ietf.org>; Thu, 14 Apr 2005 12:35:51 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM7Tr-0007GH-2a
	for isms@ietf.org; Thu, 14 Apr 2005 12:46:16 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3EGZfLR013366; 
	Thu, 14 Apr 2005 16:35:41 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3EGZPDG014165; 
	Thu, 14 Apr 2005 16:35:41 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041409354014194 ; Thu, 14 Apr 2005 09:35:40 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 09:35:40 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 09:35:40 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 12:35:37 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 12:35:15 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9036@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVAjRVlptfAi6CFSSqaZfrKvqevzwAfe0zQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sam Hartman" <hartmans-ietf@mit.edu>,
        "David T. Perkins" <dperkins@dsperkins.com>
X-OriginalArrivalTime: 14 Apr 2005 16:35:37.0914 (UTC)
	FILETIME=[FD4109A0:01C5410F]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: quoted-printable

> As I understand it, I think we're trying to allow SNMP engines to
> communicate securely using existing credentials in an existing
> infrastructure.=20

Absolutely yes.

> As such, by the time we're done, it seems reasonable to expect that
> SNMP engines using ISMS will clearly know what set of credentials
> they are using.=20

This assumption does not hold. It is one of the problem aspects.
=20
If SNMP engine knew what credentials it had, it would be much easier to
design and drop-in a "convertor" that authenticates the exchange for a
short-term key using those identities. As it is, SNMP engines operate on
behalf and with the credentials of their users. Even the user list has
to be explicitly configured in (SNMP doesn't automatically assume that
if there's /etc/password file - then every entry describes a legitimate
SNMP user).=20

It is one source of configuration inconvenience: somebody has to
explicitly configure SNMP entity and tell it what users it should
recognize and what credentials they will use.

Another configuration issue is to map each user onto Access Control
group.=20

All these are actually trivial - but constitute extra efforts and don't
happen automatically (and often require extra code which isn't there
now).  Some vendors sell configuration tools that automate the above
tasks.

And what became my standard "broken needle" in this WG - the absense of
session concept and therefore absense of two important things: (a)
separation between (and presence of both) long-term and short-term
secrets, and (b) absense of reasonable life-time of short-term secrets.


Originally SNMP assumption was - "SNMP agent knows nothing. Management
station takes care of all of the above issues, re-keys when necessary,
etc." This logic doesn't work any more.

> Associated with all the IETF security credentials I'm
> familiar with is an authenticated identity.  Sometimes this identity
> is implicit or tautological (for example the identity of a raw public
> key is often that key), but it does exist.

Identities on the hosts exist. But the automatic conversion and mapping
between them and SNMP user list - does not. Something like just
installing SSH package and having it immediately figure that there is
/etc/password file, and every entry of it defines an SSH user with
password as initial credentials. No access control or mapping issues.

It is not scientifically difficult to map from any of the existing
identities to SNMP identities, or port those identities to SNMP. The
difficulty is creating those mappings. Some want /etc/password, some -
RADIUS (RADIUS must confirm the user and give session key), some want
Kerberos or Active Directory... Wes is probably the closest in
addressing users' wishes - the issus is how to analyze (from security
point of view) the monster that must emerge to satisfy all the
requirements.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 12:45:33 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00994;
	Thu, 14 Apr 2005 12:45:33 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM7dG-0007hu-5c; Thu, 14 Apr 2005 12:55:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM7RP-0001Pb-Fw; Thu, 14 Apr 2005 12:43:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7RN-0001Ny-79
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 12:43:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00747
	for <isms@ietf.org>; Thu, 14 Apr 2005 12:43:38 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM7bN-0007Zn-Lp
	for isms@ietf.org; Thu, 14 Apr 2005 12:54:03 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3EGhHsC014968; 
	Thu, 14 Apr 2005 09:43:17 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3EGbZAd000963;
	Thu, 14 Apr 2005 09:37:35 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3EGbS9L000860; Thu, 14 Apr 2005 09:37:34 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Thu, 14 Apr 2005 09:37:27 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <tsl3btukweh.fsf@cz.mit.edu>
Message-ID: <Pine.LNX.4.10.10504140920350.26143-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4

HI Sam,

The theoretical properties and the actual deployment properties
are different. I believe, that most people are not getting this is
the fundamental cause for the major disagreements in this WG.

First, it is difficult to make sweeping statements about all
usage of SNMP technology. Dedicated purpose (and closed) network
infrastructure devices such as routers and switches are
quite different from workstations. Even routers vary
quite a bit from those that cost around $100 to ones
that are in the $1000s to those in the $10,000s.

What Wes and I have done is look at each major class of device
to determine what type of security mechanisms are used.
Likewise, we have looked at systems that run management
applications such as generic programs (MIB browsers), 
task specific programs (has builtin semantic knowledge of
the management info), and notification receivers to
determine what security mechanisms are in use.

So, one can say that in theory, for example, that both
ends of an SNMP communication path will be using X.509
certs, but in practice, this scenario would be rare.

Switching topics...
The introduction to the architecture using SNMP engines
was done to make SNMP easier to understand. I don't believe
that this was the case. Again, SNMP engines themselves
don't have an authenticated identity. SNMP engines
are like a library for SNMP applications, which have
an associated security principle. 

I'm sorry that I cannot finish this now, some unplanned
events have occured that I must take care of.

I do hope that this short message has helped.

On Wed, 13 Apr 2005, Sam Hartman wrote:

> >>>>> "David" == David T Perkins <dperkins@dsperkins.com> writes:
> 
>     David> HI, I disagree with your characterization of SNMPv3. SNMP
>     David> engines do not have authenticated identifies.
> 
>     David> I'll explain further in another message.
> 
> As I understand it, I think we're trying to allow SNMP engines to
> communicate securely using existing credentials in an existing
> infrastructure.  Please correct me if this understanding is wrong; it
> is fairly fundamental to my thinking in this WG.
> 
> As such, by the time we're done, it seems reasonable to expect that
> SNMP engines using ISMS w will clearly know what set of credentials
> they are using.  Associated with all the IETF security credentials I'm
> familiar with is an authenticated identity.  Sometimes this identity
> is implicit or tautological (for example the identity of a raw public
> key is often that key), but it does exist.
> 
> --Sam
> 
Regards,
/david t. perkins


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 12:49:40 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01467;
	Thu, 14 Apr 2005 12:49:40 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM7hE-0007sM-0U; Thu, 14 Apr 2005 13:00:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM7X2-0002Zn-QD; Thu, 14 Apr 2005 12:49:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7X1-0002Ub-C6
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 12:49:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01438
	for <isms@ietf.org>; Thu, 14 Apr 2005 12:49:23 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM7gw-0007rU-Uh
	for isms@ietf.org; Thu, 14 Apr 2005 12:59:48 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id CB64211DA2D; Thu, 14 Apr 2005 09:49:17 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Organization: Sparta
References: <Pine.LNX.4.10.10504131205460.3991-100000@shell4.bayarea.net>
	<tsl3btukweh.fsf@cz.mit.edu>
Date: Thu, 14 Apr 2005 09:49:17 -0700
In-Reply-To: <tsl3btukweh.fsf@cz.mit.edu> (Sam Hartman's message of "Wed, 13
	Apr 2005 20:57:26 -0400")
Message-ID: <sd3btt7182.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

>>>>> On Wed, 13 Apr 2005 20:57:26 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:

Sam> As I understand it, I think we're trying to allow SNMP engines to
Sam> communicate securely using existing credentials in an existing
Sam> infrastructure.  Please correct me if this understanding is wrong; it
Sam> is fairly fundamental to my thinking in this WG.

Yes, that's exactly what we're supposed to be doing.  You've obviously
read the charter because you nicely summarized most of it.  People
keep getting distracted by other topics which are, in fact, important
and even related.

In the end, and David P. has said this well many times, the goal
should be to reduce to as near-zero as possible the amount of work and
knowledge that an operator needs to make SNMP work for them.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 12:59:06 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02423;
	Thu, 14 Apr 2005 12:59:06 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM7qL-0008LC-Pk; Thu, 14 Apr 2005 13:09:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM7d4-0003zD-MB; Thu, 14 Apr 2005 12:55:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7d3-0003yH-Jt
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 12:55:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02102
	for <isms@ietf.org>; Thu, 14 Apr 2005 12:55:34 -0400 (EDT)
Received: from carter-zimmerman.mit.edu ([18.18.3.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM7mw-0008Bo-GV
	for isms@ietf.org; Thu, 14 Apr 2005 13:05:59 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 8B7C1E0063; Thu, 14 Apr 2005 12:55:30 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA9036@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Thu, 14 Apr 2005 12:55:30 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9036@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Thu, 14 Apr 2005 12:35:15 -0400")
Message-ID: <tslekddfgcd.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

    >> As I understand it, I think we're trying to allow SNMP engines
    >> to communicate securely using existing credentials in an
    >> existing infrastructure.

    Blumenthal,> Absolutely yes.

    >> As such, by the time we're done, it seems reasonable to expect
    >> that SNMP engines using ISMS will clearly know what set of
    >> credentials they are using.

    Blumenthal,> This assumption does not hold. It is one of the
    Blumenthal,> problem aspects.
 
    Blumenthal,> If SNMP engine knew what credentials it had, it would
    Blumenthal,> be much easier to design and drop-in a "convertor"
    Blumenthal,> that authenticates the exchange for a short-term key
    Blumenthal,> using those identities. As it is, SNMP engines
    Blumenthal,> operate on behalf and with the credentials of their
    Blumenthal,> users. Even the user list has to be explicitly
    Blumenthal,> configured in (SNMP doesn't automatically assume that
    Blumenthal,> if there's /etc/password file - then every entry
    Blumenthal,> describes a legitimate SNMP user).

No, I'm arguing an SNMP engine will know what credentials *it* *hash*,
not *its users have*.  I.E. an SNMP engine will know what key it
shares with a RADIUS server, what TLS certificate it has, what SSH key
it has, or what Kerberos key it has.  Other SNMP engines (managers)
will know what username/password they have, what Kerberos ticket they
have, what key they share with RADIUS, what certificate they have.

I do not think the problem before us can be solved without either
allowing for man-in-the-middle attacks or requiring that an SNMP
engine have some credential. Either solution seems to allow sessions
be established for informs.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 13:00:24 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02514;
	Thu, 14 Apr 2005 13:00:24 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM7rd-0008Qe-Nl; Thu, 14 Apr 2005 13:10:49 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM7eF-0004My-IH; Thu, 14 Apr 2005 12:56:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7eE-0004LX-Aw
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 12:56:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02247
	for <isms@ietf.org>; Thu, 14 Apr 2005 12:56:47 -0400 (EDT)
Received: from blaster.systems.pipex.net ([62.241.163.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM7o6-0008HC-Tq
	for isms@ietf.org; Thu, 14 Apr 2005 13:07:12 -0400
Received: from pc6 (1Cust95.tnt102.lnd4.gbr.da.uu.net [213.116.52.95])
	by blaster.systems.pipex.net (Postfix) with SMTP id BF613E000383;
	Thu, 14 Apr 2005 17:56:30 +0100 (BST)
Message-ID: <000801c5410a$0c3c8b60$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Robert Story" <rstory@freesnmp.com>, <isms@ietf.org>
References: <20050412131911.6b046d6d@aud>
Subject: Re: [Isms] Informal consensus on dropping out of band keying?
Date: Thu, 14 Apr 2005 15:00:47 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit

EK for preference
IBK second choice

Tom Petch

----- Original Message -----
From: "Robert Story" <rstory@freesnmp.com>
To: <isms@ietf.org>
Sent: Tuesday, April 12, 2005 7:19 PM
Subject: [Isms] Informal consensus on dropping out of band keying?


> We are just about half-way to our next dead-line, and I don't get the sense
> that we are making much progress. If we could narrow the discussion down to 2
> architectures, instead of 3, that would be some progress.
>
> Ken posted the three architectures for discussion on 3/18. Since then, there
> hasn't been too much discussion. I've summarized the preferences for people
who
> have expressed one. If I mis-characterized your preference, please let me
know.
>
>
> (OOBK = Out of band keying, IBK = In band keying, EK = Encapsulate keying)
>
> Wes Hardaker expressed a preference for IBK or EK.
> Kaushik Narayan expressed a preference for EK or IBK.
> Sharon Chisholm epxressed a preference for OOBK.
> Uri Blumenthal expressed a preference for IBK.
> Robert Story expressed a preference for IBK or EK.
> Ira McDonald expressed a preference for IBK (or at least not OOBK).
>
> So of 6 opinions, only 1 was in favor of OOBK. 5 said IBK would be ok, and 3
> also said EK would be ok.
>
> If you haven't expressed a preference for one or two of the
> architectures, now would be a good time to do so.
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 14:18:57 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08659;
	Thu, 14 Apr 2005 14:18:57 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM95d-00036r-GR; Thu, 14 Apr 2005 14:29:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM8rP-0006Uj-JZ; Thu, 14 Apr 2005 14:14:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8rN-0006UQ-CO
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 14:14:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08187
	for <isms@ietf.org>; Thu, 14 Apr 2005 14:14:27 -0400 (EDT)
Received: from ia7e0.i.pppool.de ([85.73.167.224] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM91G-0002wc-Cc
	for isms@ietf.org; Thu, 14 Apr 2005 14:24:51 -0400
Received: by boskop.local (Postfix, from userid 501)
	id 7109A27D0E4; Thu, 14 Apr 2005 09:43:52 +0200 (CEST)
Date: Thu, 14 Apr 2005 09:43:51 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Martin Soukup <msoukup@nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050414074351.GA5930@boskop.local>
Mail-Followup-To: Martin Soukup <msoukup@nortel.com>,
	"Blumenthal, Uri" <uri.blumenthal@intel.com>, isms@ietf.org
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

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

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 16:30:28 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23037;
	Thu, 14 Apr 2005 16:30:28 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMB8w-0000r4-5Y; Thu, 14 Apr 2005 16:40:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMAw4-0004s5-KI; Thu, 14 Apr 2005 16:27:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMAvy-0004rM-ST
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 16:27:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22397
	for <isms@ietf.org>; Thu, 14 Apr 2005 16:27:20 -0400 (EDT)
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMB5t-0000d5-Du
	for isms@ietf.org; Thu, 14 Apr 2005 16:37:46 -0400
Received: from [192.168.2.8] (unknown [219.101.129.242])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id CF2151BAC4D
	for <isms@ietf.org>; Thu, 14 Apr 2005 22:27:09 +0200 (CEST)
Date: Thu, 14 Apr 2005 22:27:18 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: isms@ietf.org
Message-ID: <279A73815B0B1F3D601D8978@[192.168.2.8]>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="==========50DF25A83A98367A34E9=========="
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
Subject: [Isms] Outages on IETF servers in the near future (fwd)
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48

--==========50DF25A83A98367A34E9==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

FYI.

   Juergen

------------ Forwarded Message ------------
Date: Thursday, April 14, 2005 2:35 PM -0400
From: ietf-admin@techsquare.com
To: ietf@ietf.org
Cc: wgchairs@ietf.org
Subject: Outages on IETF servers in the near future


Hi All,

I want to let you know about some scheduled maintenance activities
that may cause network and mail outages on ietf.org sites.  The
activities, which are described below, have been scheduled for the
next four Saturday mornings, from 08:00 or 09:00 until 12:00 ET.
Please check the IETF System Status Page (http://noc.ietf.org/)
periodically for updates on the status of these activities.  If you
have any questions, then please feel free to send them my way.

sb. Scott Blomquist ietf-admin@techsquare.com
-----
* Sat 4/16 - 08:00 EST - 12:00 EST
   Task:     reorganizing mailing list archives
   Affected: The mailing lists will be down for a good portion of the morning
   Comment:  I am going to try and get this down in less than 2 hours
             but I am giving myself a little extra time just in case

* Sat 4/23 - 09:00 EST - 12:00 EST
   Task:     reorganizing CNRI network infrastructure part 1
   Affected: there should be no services affected
   Comment:  just in case there are some minor network outages this is
             what is going on at CNRI

* Sat 4/30 - 09:00 EST - 12:00 EST
   Task:     Reorganizing CNRI network infrastructure part 2
   Affected: There maybe some minor (up to 1/2hour) network outages on
             ietf systems.
   Comment:  None

* Sat 5/7 - 09:00 EST - 12:00 EST
   Task:     reorganizing CNRI network infrastructure part 3
   Affected: there should be no services affected
   Comment:  just in case there are some minor network outages this is
             what is going on at CNRI



---------- End Forwarded Message ----------


--==========50DF25A83A98367A34E9==========
Content-Type: message/rfc822; name="Outages on IETF servers in the near future"

Received: from smtp0.netlab.nec.de ([10.1.1.15]) by europa.office with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 20:43:23 +0200
Received: by smtp0.netlab.nec.de (Postfix)
	id 79D01DC96; Thu, 14 Apr 2005 20:43:41 +0200 (CEST)
Delivered-To: quittek@netlab.nec.de
Received: by smtp0.netlab.nec.de (Postfix, from userid 502)
	id 6DEEB1527F; Thu, 14 Apr 2005 20:43:41 +0200 (CEST)
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id E8489DC96
	for <quittek@netlab.nec.de>; Thu, 14 Apr 2005 20:43:38 +0200 (CEST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM9H0-0003bN-QS; Thu, 14 Apr 2005 14:41:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DM9CR-00035E-MM; Thu, 14 Apr 2005 14:36:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10069;
	Thu, 14 Apr 2005 14:36:01 -0400 (EDT)
Received: from aquinas.techsquare.com ([199.190.186.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DM9M8-0003mI-UR; Thu, 14 Apr 2005 14:46:26 -0400
Received: from aquinas.techsquare.com (localhost [127.0.0.1])
	by aquinas.techsquare.com (8.12.11/8.12.8) with ESMTP id j3EIZvnI073737;
	Thu, 14 Apr 2005 14:35:57 -0400 (EDT)
	(envelope-from sb@aquinas.techsquare.com)
Received: (from sb@localhost)
	by aquinas.techsquare.com (8.12.11/8.12.11/Submit) id j3EIZvR0073734;
	Thu, 14 Apr 2005 14:35:57 -0400 (EDT) (envelope-from sb)
Date: Thu, 14 Apr 2005 14:35:57 -0400 (EDT)
Message-Id: <200504141835.j3EIZvR0073734@aquinas.techsquare.com>
From: ietf-admin@techsquare.com
To: ietf@ietf.org
User-Agent: SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=)
	APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
X-Mailman-Approved-At: Thu, 14 Apr 2005 14:41:05 -0400
Cc: wgchairs@ietf.org
Subject: Outages on IETF servers in the near future
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf-admin@techsquare.com
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/wgchairs>,
	<mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/wgchairs>,
	<mailto:wgchairs-request@ietf.org?subject=subscribe>
Sender: wgchairs-bounces@ietf.org
Errors-To: wgchairs-bounces@ietf.org
X-Spam-Status: No, score=-101.4 required=5.0 tests=BAYES_00,NO_REAL_NAME,
	USER_IN_WHITELIST autolearn=no version=3.0.1
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on atlas.office
X-Sanitizer: This message has been sanitized!
Return-Path: wgchairs-bounces@ietf.org
X-OriginalArrivalTime: 14 Apr 2005 18:43:23.0433 (UTC)
	FILETIME=[D6426990:01C54121]


Hi All,

I want to let you know about some scheduled maintenance activities
that may cause network and mail outages on ietf.org sites.  The
activities, which are described below, have been scheduled for the
next four Saturday mornings, from 08:00 or 09:00 until 12:00 ET.
Please check the IETF System Status Page (http://noc.ietf.org/)
periodically for updates on the status of these activities.  If you
have any questions, then please feel free to send them my way.

sb. Scott Blomquist ietf-admin@techsquare.com
-----
* Sat 4/16 - 08:00 EST - 12:00 EST
   Task:     reorganizing mailing list archives
   Affected: The mailing lists will be down for a good portion of the morning
   Comment:  I am going to try and get this down in less than 2 hours
             but I am giving myself a little extra time just in case

* Sat 4/23 - 09:00 EST - 12:00 EST
   Task:     reorganizing CNRI network infrastructure part 1
   Affected: there should be no services affected
   Comment:  just in case there are some minor network outages this is
             what is going on at CNRI

* Sat 4/30 - 09:00 EST - 12:00 EST
   Task:     Reorganizing CNRI network infrastructure part 2
   Affected: There maybe some minor (up to 1/2hour) network outages on
             ietf systems.
   Comment:  None

* Sat 5/7 - 09:00 EST - 12:00 EST
   Task:     reorganizing CNRI network infrastructure part 3
   Affected: there should be no services affected
   Comment:  just in case there are some minor network outages this is
             what is going on at CNRI



--==========50DF25A83A98367A34E9==========
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--==========50DF25A83A98367A34E9==========--




From isms-bounces@ietf.org  Thu Apr 14 16:42:29 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24574;
	Thu, 14 Apr 2005 16:42:29 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMBKZ-0001Wa-Og; Thu, 14 Apr 2005 16:52:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMB27-00061s-6n; Thu, 14 Apr 2005 16:33:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMB25-000610-KB
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 16:33:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23559
	for <isms@ietf.org>; Thu, 14 Apr 2005 16:33:39 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBC0-00012o-3u
	for isms@ietf.org; Thu, 14 Apr 2005 16:44:05 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3EKXVAK002431; 
	Thu, 14 Apr 2005 20:33:31 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3EKWlKP031657; 
	Thu, 14 Apr 2005 20:33:30 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041413333006898 ; Thu, 14 Apr 2005 13:33:30 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 13:33:29 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 13:33:29 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 16:33:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 16:33:07 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9313@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBHduBt3brlalBRFaIIWnpcPU1UgAExw1Q
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <j.schoenwaelder@iu-bremen.de>, "Martin Soukup" <msoukup@nortel.com>
X-OriginalArrivalTime: 14 Apr 2005 20:33:28.0619 (UTC)
	FILETIME=[3741CFB0:01C54131]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: quoted-printable

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


-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20
Sent: Thursday, April 14, 2005 12:44 AM
To: Martin Soukup
Cc: Blumenthal, Uri; isms@ietf.org
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=20
instantiate it is IMHO useless.=20

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

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 16:56:36 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26758;
	Thu, 14 Apr 2005 16:56:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMBYE-0002TM-93; Thu, 14 Apr 2005 17:07:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMBIe-000875-9u; Thu, 14 Apr 2005 16:50:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBIb-00086V-TF
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 16:50:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26060
	for <isms@ietf.org>; Thu, 14 Apr 2005 16:50:42 -0400 (EDT)
Received: from carter-zimmerman.mit.edu ([18.18.3.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBSV-00029Q-SE
	for isms@ietf.org; Thu, 14 Apr 2005 17:01:09 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id D1520E0063; Thu, 14 Apr 2005 16:50:39 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA9319@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Thu, 14 Apr 2005 16:50:39 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9319@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Thu, 14 Apr 2005 16:35:27 -0400")
Message-ID: <tslll7ldqw0.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

    >> 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...

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

I believe this is true for managers.  As I said, I believe the problem
is either vulnerable to man-in-the-middle or intractable if this is
true for agents.

However your description does not align well with my understand nor
what I'm hearing from others.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 17:03:23 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27496;
	Thu, 14 Apr 2005 17:03:23 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMBen-0002n5-8M; Thu, 14 Apr 2005 17:13:49 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMB4N-0006CO-2L; Thu, 14 Apr 2005 16:36:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMB4L-0006Bt-Eg
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 16:36:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23801
	for <isms@ietf.org>; Thu, 14 Apr 2005 16:36:07 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBEN-0001B3-UZ
	for isms@ietf.org; Thu, 14 Apr 2005 16:46:33 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3EKZs4H020857; 
	Thu, 14 Apr 2005 20:35:54 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3EKZqJl001943; 
	Thu, 14 Apr 2005 20:35:52 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041413355206560 ; Thu, 14 Apr 2005 13:35:52 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 13:35:51 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 13:35:50 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 16:35:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 16:35:27 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9319@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBEukVABWr4QL1TEGtLFNI/vJTIgAHFW6w
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 14 Apr 2005 20:35:49.0400 (UTC)
	FILETIME=[8B2B4980:01C54131]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable

> 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?).

> I do not think the problem before us can be solved without either
> allowing for man-in-the-middle attacks or requiring that an SNMP
> engine have some credential. Either solution seems to allow sessions
> be established for informs.

:-)

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 17:11:39 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29041;
	Thu, 14 Apr 2005 17:11:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMBmo-0003Mp-8L; Thu, 14 Apr 2005 17:22:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMB5W-0006Ft-VA; Thu, 14 Apr 2005 16:37:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMB5V-0006Fl-KZ
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 16:37:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23893
	for <isms@ietf.org>; Thu, 14 Apr 2005 16:37:11 -0400 (EDT)
Received: from ia7e0.i.pppool.de ([85.73.167.224] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBFQ-0001CU-C9
	for isms@ietf.org; Thu, 14 Apr 2005 16:47:37 -0400
Received: by boskop.local (Postfix, from userid 501)
	id 1713727D674; Thu, 14 Apr 2005 22:37:02 +0200 (CEST)
Date: Thu, 14 Apr 2005 22:37:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Message-ID: <20050414203701.GB8469@boskop.local>
Mail-Followup-To: "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	Martin Soukup <msoukup@nortel.com>, isms@ietf.org
References: <3DEC199BD7489643817ECA151F7C5929FA9313@pysmsx401.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9313@pysmsx401.amr.corp.intel.com>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

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

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 17:17:17 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00182;
	Thu, 14 Apr 2005 17:17:17 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMBsF-0003qm-VU; Thu, 14 Apr 2005 17:27:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMBJb-0008BC-Ac; Thu, 14 Apr 2005 16:51:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBJZ-00088m-DM
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 16:51:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26147
	for <isms@ietf.org>; Thu, 14 Apr 2005 16:51:51 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBTc-0002Au-7a
	for isms@ietf.org; Thu, 14 Apr 2005 17:02:17 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3EKpglO023687; 
	Thu, 14 Apr 2005 20:51:42 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3EKpOK1016519; 
	Thu, 14 Apr 2005 20:51:42 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041413514108242 ; Thu, 14 Apr 2005 13:51:41 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 13:51:41 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 13:51:41 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 16:51:40 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 16:51:18 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA934A@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBMbqqG0C0pgIfR2WcNyui4TSG9wAAaivQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <j.schoenwaelder@iu-bremen.de>
X-OriginalArrivalTime: 14 Apr 2005 20:51:40.0130 (UTC)
	FILETIME=[C1D92C20:01C54133]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: quoted-printable

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:j.schoenwaelder@iu-bremen.de]=20
Sent: Thursday, April 14, 2005 1:37 PM
To: Blumenthal, Uri
Cc: Martin Soukup; isms@ietf.org
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

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 17:20:16 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00647;
	Thu, 14 Apr 2005 17:20:16 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMBv9-00042L-B9; Thu, 14 Apr 2005 17:30:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMBds-0002xU-C6; Thu, 14 Apr 2005 17:12:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBdq-0002wQ-4f
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 17:12:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29203
	for <isms@ietf.org>; Thu, 14 Apr 2005 17:12:39 -0400 (EDT)
Received: from carter-zimmerman.mit.edu ([18.18.3.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBnm-0003Q4-B7
	for isms@ietf.org; Thu, 14 Apr 2005 17:23:06 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 0877AE0063; Thu, 14 Apr 2005 17:12:34 -0400 (EDT)
To: "Martin Soukup" <msoukup@nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Thu, 14 Apr 2005 17:12:34 -0400
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
	(Martin Soukup's message of "Wed, 13 Apr 2005 21:52:58 -0400")
Message-ID: <tsl64ypdpvh.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

>>>>> "Martin" == Martin Soukup <msoukup@nortel.com> writes:

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

You would need to coordinate with the ssh working group.  UNlike IKE
and EAP they don't have an explicit applicability statement for their
keys.  I talked to the working group chair and he was less negative
than I expected.

I'd be somewhat concerned about such a use.  In particular, you would
need to make sure that your protocol didn't end up being an oracle for
ssh authentication or something like that.  The ssh keys were designed
to be simple for ssh to use not a general mechanism.

Also, note that when you reuse a protocol like ssh, you hopefully at
least eventually get to a point where you reuse implementatinos.  That
means you get to take advantage of all the non-protocol deployment
simplifications of an implementation.  For example you get to reuse
the authorization infrastructure, the account creation infrastructure,
etc.

Given that it seems possible to re-use the ssh protocol not just the
keys my personal preference is to do so.  However coordinating with
the secsh working group and getting them to write an applicability
statement for their keys or just to come to consensus that your
proposed use is OK is certainly an option.

--Sam


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 17:28:12 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02117;
	Thu, 14 Apr 2005 17:28:12 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMC2p-0004bX-0Q; Thu, 14 Apr 2005 17:38:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMBd7-0002n4-T9; Thu, 14 Apr 2005 17:12:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBd4-0002lC-HC
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 17:12:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29097
	for <isms@ietf.org>; Thu, 14 Apr 2005 17:11:52 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBmz-0003Mw-DI
	for isms@ietf.org; Thu, 14 Apr 2005 17:22:18 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3ELBfAK017487; 
	Thu, 14 Apr 2005 21:11:41 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3ELBfJj001170; 
	Thu, 14 Apr 2005 21:11:41 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041414114129844 ; Thu, 14 Apr 2005 14:11:41 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 14:11:41 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 14:11:40 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 17:11:39 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 17:11:17 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA939D@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBM6Je/5lYQjQmRM+ZcN4CTTDj3AAACkNw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 14 Apr 2005 21:11:39.0320 (UTC)
	FILETIME=[8C9F0B80:01C54136]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable

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

> I believe this is true for managers.=20

SNMPv3 took great pains assuring that the engines running on manager's
and agent's side look and behave the same. Perhaps you saw statements to
this effect in the SNMP Intro and SNMP Architecture RFCs.

Please point me at the reference in the SNMPv3 RFCs that says anything
about credentials that SNMP engine *itself* has - as opposite to storing
credentials for *users* that are allowed to talk to this engine.

Similar to /etc/password file - it doesn't store the host's credentials,
but merely lists the users that are allowed to use that host. Which of
those /etc/password entries identifies the host itself?

> As I said, I believe the problem
> is either vulnerable to man-in-the-middle or intractable if this is
> true for agents.

A different issue altogether.

> However your description does not align well with my understand nor
> what I'm hearing from others.

Please kindly point me at those who tell you that SNMP engine has its
*own* credentials tied to his identity. And please point me at the SNMP
documents that lead you to that understanding.

Perhaps somebody misunderstood the key localization? User keys are
hashed with SNMP engine ID to make them unusable on other SNMP engines,
but they remain *user* credentials. It's still user's secret key,
possibly generated from his password (this idea gives heart attack to
Eric Fleischman :-). If you have 100 users - the SNMP engine will have
100 secret keys for those users (actually 200 - for encryption and
authentication :-), identified by usmUserName (unique within USM) and/or
snmpSecurityName (exportable to other SNMP modules, such as View-based
Access Control). Which one of those keys is the "engine's key" in your
opinion?

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 17:47:28 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03673;
	Thu, 14 Apr 2005 17:47:28 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMCLT-0005UE-Pp; Thu, 14 Apr 2005 17:57:55 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMC5n-00035R-4o; Thu, 14 Apr 2005 17:41:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMC5k-000334-O0
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 17:41:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03397
	for <isms@ietf.org>; Thu, 14 Apr 2005 17:41:38 -0400 (EDT)
Received: from carter-zimmerman.mit.edu ([18.18.3.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCFo-0005HG-1v
	for isms@ietf.org; Thu, 14 Apr 2005 17:52:05 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 223A1E0077; Thu, 14 Apr 2005 17:41:32 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA939D@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Thu, 14 Apr 2005 17:41:32 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA939D@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Thu, 14 Apr 2005 17:11:17 -0400")
Message-ID: <tsloechc9yr.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

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

    >> I believe this is true for managers.

    Blumenthal,> SNMPv3 took great pains assuring that the engines
    Blumenthal,> running on manager's and agent's side look and behave
    Blumenthal,> the same. Perhaps you saw statements to this effect
    Blumenthal,> in the SNMP Intro and SNMP Architecture RFCs.

    Blumenthal,> Please point me at the reference in the SNMPv3 RFCs
    Blumenthal,> that says anything about credentials that SNMP engine
    Blumenthal,> *itself* has - as opposite to storing credentials for
    Blumenthal,> *users* that are allowed to talk to this engine.

I think you are perhaps a bit too focused on USM here.

The premis of this working group is that people have infrastructure
today that has credentials.  They would like to use that
infrastructure to secure SNMP engines.  They have described several
such infrastructures.

In these infrastructures--at least in the infrastructures I mentioned
in my previous message--an engine acting in one of these
infrastructures has a natural credential to use.

It's taken as a given within the scope of this working group that
USM--particularly USM's credential model--does not meet deployment
needs.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 17:49:10 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03792;
	Thu, 14 Apr 2005 17:49:10 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMCN7-0005W0-EX; Thu, 14 Apr 2005 17:59:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMCCu-0005YJ-ME; Thu, 14 Apr 2005 17:49:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCCo-0005SM-Ff
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 17:48:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03727
	for <isms@ietf.org>; Thu, 14 Apr 2005 17:48:07 -0400 (EDT)
Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCM5-0005Uh-BR
	for isms@ietf.org; Thu, 14 Apr 2005 17:58:34 -0400
Received: from h-68-166-188-127.snvacaid.dynamic.covad.net ([68.166.188.127]
	helo=oemcomputer)
	by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DMCBy-00014b-00
	for isms@ietf.org; Thu, 14 Apr 2005 14:48:06 -0700
Message-ID: <003001c5413b$daa2b7a0$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <3DEC199BD7489643817ECA151F7C5929FA9319@pysmsx401.amr.corp.intel.com>
	<tslll7ldqw0.fsf@cz.mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 14:49:36 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Hi -

> From: "Sam Hartman" <hartmans-ietf@mit.edu>
> To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
> Cc: <isms@ietf.org>
> Sent: Thursday, April 14, 2005 1:50 PM
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
...
>     Blumenthal,> An SNMP engine has *NO* credentials of its own,
>     Blumenthal,> period. Never had. All the access is done on behalf
>     Blumenthal,> of *users* by other engines.
>
> I believe this is true for managers.  As I said, I believe the problem
> is either vulnerable to man-in-the-middle or intractable if this is
> true for agents.
>
> However your description does not align well with my understand nor
> what I'm hearing from others.
...

Uri's description is correct.  If someone could identify the text in RFC 3411-
3415 that is leading people to believe that SNMP engines have credentials
of their own, we could write an erratum.

(Slightly off topic: the lack of credentials for the engine per se leads to the
extra complexity in the handling of reports.  One may view this as a bug or
a feature, but that's the way it is.)

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 18:05:27 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05417;
	Thu, 14 Apr 2005 18:05:27 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMCcs-0006Ga-CU; Thu, 14 Apr 2005 18:15:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMCNK-0008Kg-Iv; Thu, 14 Apr 2005 17:59:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCNI-0008Jl-SW
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 17:59:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04635
	for <isms@ietf.org>; Thu, 14 Apr 2005 17:59:45 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCXM-0005zv-UW
	for isms@ietf.org; Thu, 14 Apr 2005 18:10:13 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3ELxcPO006951; 
	Thu, 14 Apr 2005 21:59:38 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3ELxXJp012888; 
	Thu, 14 Apr 2005 21:59:38 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041414593802005 ; Thu, 14 Apr 2005 14:59:38 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 14:59:38 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 14:59:37 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 17:59:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 17:59:13 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA93FE@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBOsEC039ondY7QyirjRstema6EgAABwyg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 14 Apr 2005 21:59:35.0680 (UTC)
	FILETIME=[3F10C000:01C5413D]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable

Please see below.

>>>>> "Blumenthal" =3D=3D Blumenthal, Uri <uri.blumenthal@intel.com> =
writes:

    Blumenthal> Please point me at the reference in the SNMPv3 RFCs
    Blumenthal> that says anything about credentials that SNMP engine
    Blumenthal> *itself* has - as opposite to storing credentials for
    Blumenthal> *users* that are allowed to talk to this engine.

> I think you are perhaps a bit too focused on USM here.

Not USM as much as SNMPv3 in general. But your point is taken.

> The premis of this working group is that people have infrastructure
> today that has credentials.  They would like to use that
> infrastructure to secure SNMP engines.  They have described several
> such infrastructures.

It's the relation between those infrastructures and SNMP identities, and
mapping to SNMP Access Control that is missing.

> In these infrastructures--at least in the infrastructures I mentioned
> in my previous message--an engine acting in one of these
> infrastructures has a natural credential to use.

I must have missed that message. What infrastructure is that, and what
credential is natural for SNMP engine in it?

> It's taken as a given within the scope of this working group that
> USM--particularly USM's credential model--does not meet deployment
> needs.

Deployment needs long-term credentials to establish connections and
define their life-time, and short-term secrets to protect the traffic
itself. There has been much dissent wrt. existing long-term secrets
living indpendently of existing infrastructures, and lack of short-time
secrets. USM model can play reasonably well as traffic protector
(dissenting opinion points at its weakness in anti-replay).

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 18:14:25 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06690;
	Thu, 14 Apr 2005 18:14:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMClY-0006bd-V7; Thu, 14 Apr 2005 18:24:53 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMCZ7-0002ho-R2; Thu, 14 Apr 2005 18:12:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCYq-0002dE-Lw
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 18:11:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06196
	for <isms@ietf.org>; Thu, 14 Apr 2005 18:11:33 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCim-0006Ty-DD
	for isms@ietf.org; Thu, 14 Apr 2005 18:22:01 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50) id 1DMCYe-0000XX-PZ
	for isms@ietf.org; Thu, 14 Apr 2005 18:11:32 -0400
Date: Thu, 14 Apr 2005 18:12:34 -0400
From: Robert Story <rstory@freesnmp.com>
To: isms@ietf.org
Message-ID: <20050414181234.5fd9edc1@aud>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574
Content-Transfer-Encoding: 7bit
Subject: [Isms] a plea for more useful subjects
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit

It's getting difficult to follow all the threads going on under the same
subject heading. It would be helpful if people could change the subject when
the start a new discussion.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 18:40:25 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08756;
	Thu, 14 Apr 2005 18:40:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMDAi-0007Zr-WF; Thu, 14 Apr 2005 18:50:53 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMCtt-0004rh-U5; Thu, 14 Apr 2005 18:33:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCts-0004rU-An
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 18:33:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08178
	for <isms@ietf.org>; Thu, 14 Apr 2005 18:33:17 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMD3n-0007I3-Si
	for isms@ietf.org; Thu, 14 Apr 2005 18:43:45 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 152BA11DA2D; Thu, 14 Apr 2005 15:33:14 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Organization: Sparta
References: <3DEC199BD7489643817ECA151F7C5929FA9319@pysmsx401.amr.corp.intel.com>
	<tslll7ldqw0.fsf@cz.mit.edu>
	<003001c5413b$daa2b7a0$7f1afea9@oemcomputer>
Date: Thu, 14 Apr 2005 15:33:12 -0700
In-Reply-To: <003001c5413b$daa2b7a0$7f1afea9@oemcomputer> (Randy Presuhn's
	message of "Thu, 14 Apr 2005 14:49:36 -0700")
Message-ID: <sdaco12dlj.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d

>>>>> On Thu, 14 Apr 2005 14:49:36 -0700, "Randy Presuhn" <randy_presuhn@mindspring.com> said:

Randy> Uri's description is correct.  If someone could identify the
Randy> text in RFC 3411- 3415 that is leading people to believe that
Randy> SNMP engines have credentials of their own, we could write an
Randy> erratum.

Randy> (Slightly off topic: the lack of credentials for the engine per
Randy> se leads to the extra complexity in the handling of reports.
Randy> One may view this as a bug or a feature, but that's the way it
Randy> is.)

I think the disconnection here is that the SNMP people keep stating
that no existing engine has any credentials, and that Sam (and
possibly others) is saying that SNMP with an ISMS solution in place
will result in SNMP engines with credentials possibly associated with
it in the future.  EG, if SSH is used then the SSH Host Key will
likely be a credential for future SNMP engines that are configured to
allow for an SNMP/SSH transport and at *that* point an engine will
functionally have a credential.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 19:03:58 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10101;
	Thu, 14 Apr 2005 19:03:58 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMDXW-0008V7-Ic; Thu, 14 Apr 2005 19:14:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMDGE-00079R-LZ; Thu, 14 Apr 2005 18:56:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMDGB-00078T-72
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 18:56:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09785
	for <isms@ietf.org>; Thu, 14 Apr 2005 18:56:19 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMDQ6-0008Ev-J5
	for isms@ietf.org; Thu, 14 Apr 2005 19:06:48 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,
	v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3EMuClO022261
	for <isms@ietf.org>; Thu, 14 Apr 2005 22:56:12 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,
	v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3EMtrJx021703
	for <isms@ietf.org>; Thu, 14 Apr 2005 22:56:12 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041415561206830
	for <isms@ietf.org>; Thu, 14 Apr 2005 15:56:12 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 15:56:11 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 15:56:11 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 18:56:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 18:55:48 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9439@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBRApt3evmAzooQfGWUQOqscoAFgAAByWg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <isms@ietf.org>
X-OriginalArrivalTime: 14 Apr 2005 22:56:10.0466 (UTC)
	FILETIME=[2683FC20:01C54145]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable

> I think the disconnection here is that the SNMP people keep stating
> that no existing engine has any credentials, and that Sam (and
> possibly others) is saying that SNMP with an ISMS solution in place
> will result in SNMP engines with credentials possibly associated with
> it in the future.=20

I see. Makes sense. Though in that case it would've been better to
explicitly state that despite speaking in present tense and seemingly
about the existing setup (that can be used for our purposes), it applies
only to possible future.

> EG, if SSH is used then the SSH Host Key will
> likely be a credential for future SNMP engines that are configured to
> allow for an SNMP/SSH transport and at *that* point an engine will
> functionally have a credential.

I see. Yes it can work. Does it imply that the SSH Host key will be
shared between SSH daemon and SNMP engine? And the host identity this
key is bound to, will be shared by all the SNMP engines that may run on
that host? Or will each of them generate its own PK pair?
--=20
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 19:28:29 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11224;
	Thu, 14 Apr 2005 19:28:29 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMDvF-0000tX-1e; Thu, 14 Apr 2005 19:38:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMDiJ-0001Tb-Ry; Thu, 14 Apr 2005 19:25:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMDiF-0001PK-QG
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 19:25:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11143
	for <isms@ietf.org>; Thu, 14 Apr 2005 19:25:20 -0400 (EDT)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251]
	helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMDsB-0000nx-TC
	for isms@ietf.org; Thu, 14 Apr 2005 19:35:49 -0400
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO0055E4;
	14 Apr 05 19:34:05 -0400
Received: from spooler by Lamicro.com (Mercury/32 v3.32);
	14 Apr 05 19:33:48 -0400
Received: from connotech.com (209.71.204.111) by SMTP.Lamicro.com (Mercury/32
	v3.32) with ESMTP ID MG0055E2; 14 Apr 05 19:33:35 -0400
Message-ID: <425F0218.4080908@connotech.com>
Date: Thu, 14 Apr 2005 19:51:52 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: j.schoenwaelder@iu-bremen.de
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA9313@pysmsx401.amr.corp.intel.com>
	<20050414203701.GB8469@boskop.local>
In-Reply-To: <20050414203701.GB8469@boskop.local>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit



Juergen Schoenwaelder wrote:

> 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?

RADIUS?

RADIUS with an
"implementation-specific" attribute in an Access-Request packet to
indicate to the RADIUS server that some "Authenticate Only"
service type request is a request to a) authenticate the end-
user, b) validate that the end-user is allowed SNMPv3 agent
registration, and c) convey the required keying information to the
NAS in the network device, in an implementation-specific
attribute to the RADIUS Access-Accept packet.

> 
> /js
> 

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 19:54:08 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12809;
	Thu, 14 Apr 2005 19:54:07 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMEK0-0001tE-SL; Thu, 14 Apr 2005 20:04:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DME3A-0003NJ-JR; Thu, 14 Apr 2005 19:47:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DME39-0003N1-Oe
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 19:47:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12356
	for <isms@ietf.org>; Thu, 14 Apr 2005 19:46:56 -0400 (EDT)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251]
	helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMED5-0001ZA-Vw
	for isms@ietf.org; Thu, 14 Apr 2005 19:57:25 -0400
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO00561C;
	14 Apr 05 19:55:41 -0400
Received: from spooler by Lamicro.com (Mercury/32 v3.32);
	14 Apr 05 19:55:27 -0400
Received: from connotech.com (209.71.204.111) by SMTP.Lamicro.com (Mercury/32
	v3.32) with ESMTP ID MG00561A; 14 Apr 05 19:55:17 -0400
Message-ID: <425F0731.3020009@connotech.com>
Date: Thu, 14 Apr 2005 20:13:37 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA9319@pysmsx401.amr.corp.intel.com>
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9319@pysmsx401.amr.corp.intel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit



Blumenthal, Uri wrote:

>>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?).

You would hope that once the SNMP engine gets its initial credentials 
(e.g. a symmetric key, or a private key certified by a PKI certificate) 
  and a link to existing infrastructure, the individual SNMP user 
authentication will be automated. Hence reduced burden, hence isms goal 
reached.


-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 20:04:12 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13685;
	Thu, 14 Apr 2005 20:04:12 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMETm-0002H2-KJ; Thu, 14 Apr 2005 20:14:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMEJ5-0006tn-6v; Thu, 14 Apr 2005 20:03:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMEJ2-0006st-Vr
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 20:03:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13394
	for <isms@ietf.org>; Thu, 14 Apr 2005 20:03:23 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMESz-0002FS-AO
	for isms@ietf.org; Thu, 14 Apr 2005 20:13:50 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,
	v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3F03E4H004818
	for <isms@ietf.org>; Fri, 15 Apr 2005 00:03:14 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com
	[132.233.42.129])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,
	v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3F035DE011124
	for <isms@ietf.org>; Fri, 15 Apr 2005 00:03:14 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041417030810997
	for <isms@ietf.org>; Thu, 14 Apr 2005 17:03:09 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 17:03:02 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 17:03:02 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 20:03:00 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 20:02:38 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA946F@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBTET4b7k2kReuTOOCUkGDqR2dIgAAVTvg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 00:03:00.0573 (UTC)
	FILETIME=[7CB9C0D0:01C5414E]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: quoted-printable

>> An SNMP engine has *NO* credentials of its own, period. Never had.
All
>> the access is done on behalf of *users* by other engines.
>>=20
>> 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?).
>
> You would hope that once the SNMP engine gets its initial credentials=20
> (e.g. a symmetric key, or a private key certified by a PKI
certificate)=20
> and a link to existing infrastructure, the individual SNMP user=20
> authentication will be automated. Hence reduced burden, hence isms
goal=20
> reached.

Yes, but not so fast! :-)

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.=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 20:16:26 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14523;
	Thu, 14 Apr 2005 20:16:26 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMEfd-0002ke-DS; Thu, 14 Apr 2005 20:26:53 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMEVN-0003XN-Rm; Thu, 14 Apr 2005 20:16:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMEVK-0003Td-Iw
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 20:16:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14483
	for <isms@ietf.org>; Thu, 14 Apr 2005 20:16:11 -0400 (EDT)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251]
	helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMEfN-0002jd-52
	for isms@ietf.org; Thu, 14 Apr 2005 20:26:39 -0400
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO00566D;
	14 Apr 05 20:24:54 -0400
Received: from spooler by Lamicro.com (Mercury/32 v3.32);
	14 Apr 05 20:24:36 -0400
Received: from connotech.com (209.71.204.103) by SMTP.Lamicro.com (Mercury/32
	v3.32) with ESMTP ID MG00566C; 14 Apr 05 20:24:33 -0400
Message-ID: <425F0E0F.7040305@connotech.com>
Date: Thu, 14 Apr 2005 20:42:55 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA946F@pysmsx401.amr.corp.intel.com>
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA946F@pysmsx401.amr.corp.intel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit



Blumenthal, Uri wrote:

> 
> 
> Yes, but not so fast! :-)
> 
> 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!

> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 20:23:31 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14834;
	Thu, 14 Apr 2005 20:23:31 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMEmV-000336-32; Thu, 14 Apr 2005 20:33:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMEc8-0006O0-01; Thu, 14 Apr 2005 20:23:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMEc0-0006IM-5v
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 20:23:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14825
	for <isms@ietf.org>; Thu, 14 Apr 2005 20:22:58 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMElw-0002yV-Pj
	for isms@ietf.org; Thu, 14 Apr 2005 20:33:26 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3F0Mmdc013192; 
	Fri, 15 Apr 2005 00:22:48 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3F0MkD6003291; 
	Fri, 15 Apr 2005 00:22:48 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041417224814216 ; Thu, 14 Apr 2005 17:22:48 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 17:22:48 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 17:22:48 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Apr 2005 20:22:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 20:22:24 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA947C@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBUFbBlL9hVIoYQwutRAxVnIuyrgAAC+Wg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Thierry Moreau" <thierry.moreau@connotech.com>
X-OriginalArrivalTime: 15 Apr 2005 00:22:46.0449 (UTC)
	FILETIME=[3F901210:01C54151]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable

>> 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.
>>=20
>> 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.=20
>
>If user mapping to VACM can be in a centralized database accessible to=20
>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.=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 20:35:39 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16028;
	Thu, 14 Apr 2005 20:35:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMEyE-0003V5-J5; Thu, 14 Apr 2005 20:46:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMEnq-0004GM-Kz; Thu, 14 Apr 2005 20:35:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMEnn-0004BM-I5
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 20:35:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15997
	for <isms@ietf.org>; Thu, 14 Apr 2005 20:35:08 -0400 (EDT)
Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMExi-0003Um-Qk
	for isms@ietf.org; Thu, 14 Apr 2005 20:45:36 -0400
Received: from h-68-165-3-199.snvacaid.dynamic.covad.net ([68.165.3.199]
	helo=oemcomputer)
	by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DMEna-00020D-00
	for isms@ietf.org; Thu, 14 Apr 2005 17:35:06 -0700
Message-ID: <001201c54153$2ec23e20$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <3DEC199BD7489643817ECA151F7C5929FA947C@pysmsx401.amr.corp.intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Thu, 14 Apr 2005 17:36:36 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Hi -

> From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
> To: "Thierry Moreau" <thierry.moreau@connotech.com>
> Cc: <isms@ietf.org>
> Sent: Thursday, April 14, 2005 5:22 PM
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
...
> 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.
...

Sounds a lot like EUSM.  (not that that'd be a bad thing)

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Thu Apr 14 20:44:32 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16450;
	Thu, 14 Apr 2005 20:44:32 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMF6q-0003nc-0F; Thu, 14 Apr 2005 20:55:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMEvL-0006mU-N0; Thu, 14 Apr 2005 20:43:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMEv3-0006da-OT
	for isms@megatron.ietf.org; Thu, 14 Apr 2005 20:42:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16330
	for <isms@ietf.org>; Thu, 14 Apr 2005 20:42:34 -0400 (EDT)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251]
	helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMF4v-0003iL-0G
	for isms@ietf.org; Thu, 14 Apr 2005 20:53:02 -0400
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO005695;
	14 Apr 05 20:51:18 -0400
Received: from spooler by Lamicro.com (Mercury/32 v3.32);
	14 Apr 05 20:51:13 -0400
Received: from connotech.com (209.71.204.103) by SMTP.Lamicro.com (Mercury/32
	v3.32) with ESMTP ID MG005694; 14 Apr 05 20:51:03 -0400
Message-ID: <425F1436.5000805@connotech.com>
Date: Thu, 14 Apr 2005 21:09:10 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA947C@pysmsx401.amr.corp.intel.com>
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA947C@pysmsx401.amr.corp.intel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit



Blumenthal, Uri wrote:

>>>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 :-);

See my previous post on "A session-less fix to SNMP security issues?", 
section 3.4.3.

>  - 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. 

Indeed.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 04:41:27 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07199;
	Fri, 15 Apr 2005 04:41:27 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMMYR-0003w2-7h; Fri, 15 Apr 2005 04:51:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMMHb-0003kG-28; Fri, 15 Apr 2005 04:34:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMMHY-0003ir-9j
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 04:34:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06696
	for <isms@ietf.org>; Fri, 15 Apr 2005 04:34:22 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMMRZ-0003ce-9h
	for isms@ietf.org; Fri, 15 Apr 2005 04:44:54 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 15 Apr 2005 01:34:13 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3F8Y7Kx013299;
	Fri, 15 Apr 2005 01:34:07 -0700 (PDT)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp4163.cisco.com [10.61.80.66])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3F8PUls022717;
	Fri, 15 Apr 2005 01:25:30 -0700
Message-ID: <425F7C80.8050007@cisco.com>
Date: Fri, 15 Apr 2005 10:34:08 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] SSH / Reusability / etc
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
	<tsl64ypdpvh.fsf@cz.mit.edu>
In-Reply-To: <tsl64ypdpvh.fsf@cz.mit.edu>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113553531.711310"; x:"432200"; a:"rsa-sha1"; b:"nofws:146";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"k5qjaOIGgEKeYfGrVmDHh569hD7Hnya0+TTHeCaP2sLBgvLqOgvUiHrEFzfVpMTUP1nGYMtA"
	"WiPaAadAYTntDOV6oJDZMBrvtRM/dExLW0z13iTjETkhvQ5c4FCqXq0rTAfUY2PvcVirVqFkux+"
	"I6VCoh3N8eim78G82MUKSs1E=";
	c:"Date: Fri, 15 Apr 2005 10:34:08 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: [Isms] SSH / Reusability / etc"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit

Sam,

If I read your messages your are saying that it is okay to explore use 
of the ssh protocol, but that use of just the keys wouldn't float your 
boat.  Is that a fair summary?

Eliot

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 07:17:07 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17847;
	Fri, 15 Apr 2005 07:17:07 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMOz5-000113-Iy; Fri, 15 Apr 2005 07:27:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMOik-00055k-TE; Fri, 15 Apr 2005 07:10:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMOiZ-00054h-OR
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 07:10:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17447
	for <isms@ietf.org>; Fri, 15 Apr 2005 07:10:27 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMOse-0000i3-96
	for isms@ietf.org; Fri, 15 Apr 2005 07:21:01 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3FBA8a10992
	for <isms@ietf.org>; Fri, 15 Apr 2005 07:10:08 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3FBACh24095
	for <isms@ietf.org>; Fri, 15 Apr 2005 07:10:12 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RKL31>; Fri, 15 Apr 2005 07:10:08 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B37@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 07:10:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0194511645=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0194511645==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C541AB.AC024F0B"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C541AB.AC024F0B
Content-Type: text/plain

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.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn
> Sent: April 14, 2005 8:37 PM
> To: isms@ietf.org
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> Hi -
> 
> > From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
> > To: "Thierry Moreau" <thierry.moreau@connotech.com>
> > Cc: <isms@ietf.org>
> > Sent: Thursday, April 14, 2005 5:22 PM
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> ...
> > 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.
> ...
> 
> Sounds a lot like EUSM.  (not that that'd be a bad thing)
> 
> Randy
> 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

------_=_NextPart_001_01C541AB.AC024F0B
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>RADIUS &quot;Access-Accept&quot; indicates a =
successful authenthentication response for a user.</FONT>
</P>

<P><FONT SIZE=3D2>The Access-Accept already returns a =
&quot;Session-Timeout&quot;, defined as &quot;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 &quot;absolute =
timeout.&quot;&quot;.</FONT></P>

<P><FONT SIZE=3D2>RADIUS is commonly used to return policy (e.g. VACM =
group mapping) and specific uses have been standardized.</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Uri, I'm not entirely sure what you meant by =
&quot;identity to use&quot; below since authentication presumes an =
identity was already provided?</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Randy Presuhn</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 14, 2005 8:37 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi -</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: &quot;Blumenthal, Uri&quot; =
&lt;uri.blumenthal@intel.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: &quot;Thierry Moreau&quot; =
&lt;thierry.moreau@connotech.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: &lt;isms@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, April 14, 2005 5:22 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [Isms] Discussion: =
Architecture direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So in case of RADIUS, the &quot;access =
granted&quot; should be accompanied by:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; - generated fresh keying for this =
session (including its </FONT>
<BR><FONT SIZE=3D2>&gt; life-time);</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; - identity to use for this =
connection (as probably nobody wants to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; configure user database on the SNMP agent =
:-);</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; - mapping of that identity onto an =
existing VACM group.</FONT>
<BR><FONT SIZE=3D2>&gt; ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sounds a lot like EUSM.&nbsp; (not that that'd =
be a bad thing)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Randy</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C541AB.AC024F0B--


--===============0194511645==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0194511645==--



From isms-bounces@ietf.org  Fri Apr 15 07:33:42 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19060;
	Fri, 15 Apr 2005 07:33:42 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMPF8-0001ak-UQ; Fri, 15 Apr 2005 07:44:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMP12-0007Ps-9t; Fri, 15 Apr 2005 07:29:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMP0z-0007NI-LL
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 07:29:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18803
	for <isms@ietf.org>; Fri, 15 Apr 2005 07:29:33 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMPB7-0001RB-5l
	for isms@ietf.org; Fri, 15 Apr 2005 07:40:05 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3FBTCa12992; Fri, 15 Apr 2005 07:29:12 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3FBTFh01556; Fri, 15 Apr 2005 07:29:15 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RKLTF>; Fri, 15 Apr 2005 07:29:11 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B38@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>,
        Thierry Moreau
	<thierry.moreau@connotech.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 07:29:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1556043151=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1556043151==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C541AE.561E75D5"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C541AE.561E75D5
Content-Type: text/plain

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.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri
> Sent: April 14, 2005 8:22 PM
> To: Thierry Moreau
> Cc: isms@ietf.org
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> >> 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. 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

------_=_NextPart_001_01C541AE.561E75D5
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Actually, I think it could be zero touch on the AAA =
server side, with minimal SNMP engine impact. </FONT>
</P>

<P><FONT SIZE=3D2>1. The returning of session lifetime is already =
supported in RADIUS {Session-Timeout}</FONT>
<BR><FONT SIZE=3D2>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)</FONT></P>

<P><FONT SIZE=3D2>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)</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Blumenthal, Uri</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 14, 2005 8:22 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Thierry Moreau</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; RADIUS server or whatever is =
authorizing the user, must provide</FONT>
<BR><FONT SIZE=3D2>&gt; (besides</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; the keying, of course) the mapping to =
SNMP VACM, so that </FONT>
<BR><FONT SIZE=3D2>&gt; the actual </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; access control can be =
performed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; We must solve the first problem first =
- getting users</FONT>
<BR><FONT SIZE=3D2>&gt; RADIUS-authorized</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; (for example). But we must also =
realize that it is only a </FONT>
<BR><FONT SIZE=3D2>&gt; half of the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; issue.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;If user mapping to VACM can be in a =
centralized database </FONT>
<BR><FONT SIZE=3D2>&gt; accessible to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;the RADIUS server, perhaps we solve half of =
the other half of the</FONT>
<BR><FONT SIZE=3D2>&gt; issue!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No reason why it cannot be there. It's just =
another set of </FONT>
<BR><FONT SIZE=3D2>&gt; data, related</FONT>
<BR><FONT SIZE=3D2>&gt; to users and their access rights.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So in case of RADIUS, the &quot;access =
granted&quot; should be accompanied by:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - generated fresh keying for this session =
(including its life-time);</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - identity to use for this connection (as =
probably nobody wants to</FONT>
<BR><FONT SIZE=3D2>&gt; configure user database on the SNMP agent :-);</=
FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - mapping of that identity onto an =
existing VACM group.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Not that hard really...&nbsp; But somebody has =
to add that info to the</FONT>
<BR><FONT SIZE=3D2>&gt; existing server database. So this solution will =
utilize the existing</FONT>
<BR><FONT SIZE=3D2>&gt; infrastructure - but it can never be &quot;zero =
touch&quot;. Something </FONT>
<BR><FONT SIZE=3D2>&gt; extra will</FONT>
<BR><FONT SIZE=3D2>&gt; have to be done. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C541AE.561E75D5--


--===============1556043151==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1556043151==--



From isms-bounces@ietf.org  Fri Apr 15 07:33:46 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19079;
	Fri, 15 Apr 2005 07:33:46 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMPFC-0001ao-OL; Fri, 15 Apr 2005 07:44:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMP3n-0008Jn-B1; Fri, 15 Apr 2005 07:32:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMP3m-0008JR-0g
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 07:32:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18984
	for <isms@ietf.org>; Fri, 15 Apr 2005 07:32:29 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMPDx-0001Yn-KH
	for isms@ietf.org; Fri, 15 Apr 2005 07:43:01 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3FBVHa13295; Fri, 15 Apr 2005 07:31:18 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3FBVKh02284; Fri, 15 Apr 2005 07:31:20 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RKLTV>; Fri, 15 Apr 2005 07:31:16 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B39@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Eliot Lear'" <lear@cisco.com>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: RE: [Isms] SSH / Reusability / etc
Date: Fri, 15 Apr 2005 07:31:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0007364129=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0007364129==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C541AE.9FF44905"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C541AE.9FF44905
Content-Type: text/plain

I absolutely agree with the sentiment, whether Sam agrees or not.

Martin.

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: April 15, 2005 4:34 AM
> To: Sam Hartman
> Cc: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
> Subject: Re: [Isms] SSH / Reusability / etc
> 
> 
> Sam,
> 
> If I read your messages your are saying that it is okay to 
> explore use 
> of the ssh protocol, but that use of just the keys wouldn't 
> float your 
> boat.  Is that a fair summary?
> 
> Eliot
> 
> 

------_=_NextPart_001_01C541AE.9FF44905
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>RE: [Isms] SSH / Reusability / etc</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I absolutely agree with the sentiment, whether Sam agrees or not.</FONT>
</P>

<P><FONT SIZE=2>Martin.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Eliot Lear [<A HREF="mailto:lear@cisco.com">mailto:lear@cisco.com</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: April 15, 2005 4:34 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Sam Hartman</FONT>
<BR><FONT SIZE=2>&gt; Cc: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [Isms] SSH / Reusability / etc</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sam,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If I read your messages your are saying that it is okay to </FONT>
<BR><FONT SIZE=2>&gt; explore use </FONT>
<BR><FONT SIZE=2>&gt; of the ssh protocol, but that use of just the keys wouldn't </FONT>
<BR><FONT SIZE=2>&gt; float your </FONT>
<BR><FONT SIZE=2>&gt; boat.&nbsp; Is that a fair summary?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Eliot</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C541AE.9FF44905--


--===============0007364129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0007364129==--



From isms-bounces@ietf.org  Fri Apr 15 11:02:47 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07537;
	Fri, 15 Apr 2005 11:02:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMSVW-0001SZ-AP; Fri, 15 Apr 2005 11:13:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMSH0-0005T7-R3; Fri, 15 Apr 2005 10:58:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMSGz-0005T2-RX
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 10:58:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07206
	for <isms@ietf.org>; Fri, 15 Apr 2005 10:58:19 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSRC-0001Fh-Ph
	for isms@ietf.org; Fri, 15 Apr 2005 11:08:55 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3FEwB40011347; 
	Fri, 15 Apr 2005 14:58:11 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3FEw8Kf002337; 
	Fri, 15 Apr 2005 14:58:11 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041507580902715 ; Fri, 15 Apr 2005 07:58:09 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 07:58:09 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 07:58:08 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 10:58:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 10:57:44 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9681@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBrezEYWUkLJ4KRdmQxVFMeEnk7QAHKihQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Martin Soukup" <msoukup@nortel.com>, <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 14:58:07.0536 (UTC)
	FILETIME=[8891F300:01C541CB]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.6 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0316890918=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 6907f330301e69261fa73bed91449a20

This is a multi-part message in MIME format.

--===============0316890918==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C541CB.8825AB73"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C541CB.8825AB73
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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=3DusmSecurityName=3D"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: isms-bounces@lists.ietf.org
[mailto:isms-bounces@lists.ietf.org] On Behalf Of Martin Soukup
	Sent: Friday, April 15, 2005 4:10 AM
	To: isms@ietf.org
	Subject: RE: [Isms] Discussion: Architecture direction for ISMS
=09
=09

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

	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.=20

	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.=20

	> -----Original Message-----=20
	> From: isms-bounces@lists.ietf.org=20
	> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy
Presuhn=20
	> Sent: April 14, 2005 8:37 PM=20
	> To: isms@ietf.org=20
	> Subject: Re: [Isms] Discussion: Architecture direction for
ISMS=20
	>=20
	>=20
	> Hi -=20
	>=20
	> > From: "Blumenthal, Uri" <uri.blumenthal@intel.com>=20
	> > To: "Thierry Moreau" <thierry.moreau@connotech.com>=20
	> > Cc: <isms@ietf.org>=20
	> > Sent: Thursday, April 14, 2005 5:22 PM=20
	> > Subject: RE: [Isms] Discussion: Architecture direction for
ISMS=20
	> ...=20
	> > So in case of RADIUS, the "access granted" should be
accompanied by:=20
	> >=20
	> >  - generated fresh keying for this session (including its=20
	> life-time);=20
	> >  - identity to use for this connection (as probably nobody
wants to=20
	> > configure user database on the SNMP agent :-);=20
	> >  - mapping of that identity onto an existing VACM group.=20
	> ...=20
	>=20
	> Sounds a lot like EUSM.  (not that that'd be a bad thing)=20
	>=20
	> Randy=20
	>=20
	>=20
	>=20
	>=20
	> _______________________________________________=20
	> Isms mailing list=20
	> Isms@lists.ietf.org=20
	> https://www1.ietf.org/mailman/listinfo/isms=20
	>=20
	>=20


------_=_NextPart_001_01C541CB.8825AB73
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Isms] Discussion: Architecture direction for =
ISMS</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1492" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D762195114-15042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Every=20
existing infrastructure has its own way to identify its users. More =
often than=20
not, these identitites do not match. One of the&nbsp;complaints wrt. =
SNMPv3=20
deployment is the fact that its set of identities does not [necessarily] =
match=20
those other ones - and thus user datastore has to be filled during =
provisioning=20
or configuration time. Thus when a RADIUS user "msoukup" request SNMP =
access and=20
is authenticated+authorized, RADIUS must tell SNMP engine what identity =
to use=20
in the SNMP traffic packets. For USM, it could be dynamically created =
entry with=20
usmUserName=3DusmSecurityName=3D"msoukup", or a reference to an =
already-existing one=20
(then RADIUS should tell which, or there should be a rule by which the =
SNMP=20
engine can figure it out by itself). For other systems - perhaps they =
can be=20
made to just directly&nbsp;take the identity that RADIUS just authorized =
-=20
but&nbsp;I don't think it would be any easier.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> isms-bounces@lists.ietf.org=20
  [mailto:isms-bounces@lists.ietf.org] <B>On Behalf Of </B>Martin=20
  Soukup<BR><B>Sent:</B> Friday, April 15, 2005 4:10 AM<BR><B>To:</B>=20
  isms@ietf.org<BR><B>Subject:</B> RE: [Isms] Discussion: Architecture =
direction=20
  for ISMS<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT size=3D2>RADIUS "Access-Accept" indicates a successful=20
  authenthentication response for a user.</FONT> </P>
  <P><FONT size=3D2>The Access-Accept already returns a =
"Session-Timeout", defined=20
  as "Sets the maximum number of seconds of service to be provided to =
the user=20
  before the session terminates. This attribute value becomes the =
per-user=20
  "absolute timeout."".</FONT></P>
  <P><FONT size=3D2>RADIUS is commonly used to return policy (e.g. VACM =
group=20
  mapping) and specific uses have been standardized.</FONT> </P>
  <P><FONT size=3D2>This definitely fits well with EUSM, if something =
which can be=20
  tunneled over RADIUS can generate the key binding. This is why I like=20
  RADIUS.</FONT></P>
  <P><FONT size=3D2>Uri, I'm not entirely sure what you meant by =
"identity to use"=20
  below since authentication presumes an identity was already=20
  provided?</FONT></P>
  <P><FONT size=3D2>Martin.</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: isms-bounces@lists.ietf.org </FONT><BR><FONT size=3D2>&gt; [<A=20
  =
href=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.iet=
f.org</A>]=20
  On Behalf Of Randy Presuhn</FONT> <BR><FONT size=3D2>&gt; Sent: April =
14, 2005=20
  8:37 PM</FONT> <BR><FONT size=3D2>&gt; To: isms@ietf.org</FONT> =
<BR><FONT=20
  size=3D2>&gt; Subject: Re: [Isms] Discussion: Architecture direction =
for=20
  ISMS</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Hi -</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; From: "Blumenthal, Uri"=20
  &lt;uri.blumenthal@intel.com&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
To:=20
  "Thierry Moreau" &lt;thierry.moreau@connotech.com&gt;</FONT> <BR><FONT =

  size=3D2>&gt; &gt; Cc: &lt;isms@ietf.org&gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  Sent: Thursday, April 14, 2005 5:22 PM</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  Subject: RE: [Isms] Discussion: Architecture direction for ISMS</FONT> =

  <BR><FONT size=3D2>&gt; ...</FONT> <BR><FONT size=3D2>&gt; &gt; So in =
case of=20
  RADIUS, the "access granted" should be accompanied by:</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; - =
generated fresh=20
  keying for this session (including its </FONT><BR><FONT size=3D2>&gt;=20
  life-time);</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; - identity to =
use for this=20
  connection (as probably nobody wants to </FONT><BR><FONT size=3D2>&gt; =
&gt;=20
  configure user database on the SNMP agent :-);</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;&nbsp; - mapping of that identity onto an existing VACM =
group.</FONT>=20
  <BR><FONT size=3D2>&gt; ...</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; Sounds a lot like EUSM.&nbsp; (not that that'd be a bad=20
  thing)</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Randy</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  Isms mailing list</FONT> <BR><FONT size=3D2>&gt; =
Isms@lists.ietf.org</FONT>=20
  <BR><FONT size=3D2>&gt; <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
  target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C541CB.8825AB73--


--===============0316890918==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0316890918==--



From isms-bounces@ietf.org  Fri Apr 15 12:08:27 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17228;
	Fri, 15 Apr 2005 12:08:27 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMTWt-0005YD-9x; Fri, 15 Apr 2005 12:18:51 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMTFP-0004kX-GU; Fri, 15 Apr 2005 12:00:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTFN-0004jN-GZ
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 12:00:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16005
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:00:41 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTIy-0004Cq-E1
	for isms@ietf.org; Fri, 15 Apr 2005 12:04:31 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3FFrWH20311; Fri, 15 Apr 2005 11:53:33 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3FFrZU22227; Fri, 15 Apr 2005 11:53:36 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RKSHP>; Fri, 15 Apr 2005 11:53:31 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B42@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>,
        "'isms@ietf.org'"
	<isms@ietf.org>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 11:53:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1101301027=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1101301027==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C541D3.41D41FD3"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C541D3.41D41FD3
Content-Type: text/plain

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:uri.blumenthal@intel.com] 
Sent: Friday, April 15, 2005 10:58 AM
To: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
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.


  _____  

From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Martin Soukup
Sent: Friday, April 15, 2005 4:10 AM
To: isms@ietf.org
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. 

> -----Original Message----- 
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org <mailto:isms-bounces@lists.ietf.org> ]
On Behalf Of Randy Presuhn 
> Sent: April 14, 2005 8:37 PM 
> To: isms@ietf.org 
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS 
> 
> 
> Hi - 
> 
> > From: "Blumenthal, Uri" <uri.blumenthal@intel.com> 
> > To: "Thierry Moreau" <thierry.moreau@connotech.com> 
> > Cc: <isms@ietf.org> 
> > Sent: Thursday, April 14, 2005 5:22 PM 
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS 
> ... 
> > 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. 
> ... 
> 
> Sounds a lot like EUSM.  (not that that'd be a bad thing) 
> 
> Randy 
> 
> 
> 
> 
> _______________________________________________ 
> Isms mailing list 
> Isms@lists.ietf.org 
> https://www1.ietf.org/mailman/listinfo/isms
<https://www1.ietf.org/mailman/listinfo/isms>  
> 
> 


------_=_NextPart_001_01C541D3.41D41FD3
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1491" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=600423015-15042005><FONT face=Arial color=#0000ff size=2>Ah - 
yes. The return of this information (User-Name) in the Access-Accept would be 
supported through configuration of any standard RADIUS 
server.</FONT></SPAN></DIV>
<DIV><SPAN class=600423015-15042005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=600423015-15042005><FONT face=Arial color=#0000ff 
size=2>martin.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Blumenthal, Uri 
  [mailto:uri.blumenthal@intel.com] <BR><B>Sent:</B> Friday, April 15, 2005 
  10:58 AM<BR><B>To:</B> Soukup, Martin [CAR:5K50:EXCH]; 
  isms@ietf.org<BR><B>Subject:</B> RE: [Isms] Discussion: Architecture direction 
  for ISMS<BR><BR></FONT></DIV>
  <DIV><SPAN class=762195114-15042005><FONT face=Arial color=#0000ff 
  size=2>Every existing infrastructure has its own way to identify its users. 
  More often than not, these identitites do not match. One of 
  the&nbsp;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&nbsp;take the identity that RADIUS just authorized - 
  but&nbsp;I don't think it would be any easier.</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
    <HR tabIndex=-1>
    <FONT face=Tahoma size=2><B>From:</B> isms-bounces@lists.ietf.org 
    [mailto:isms-bounces@lists.ietf.org] <B>On Behalf Of </B>Martin 
    Soukup<BR><B>Sent:</B> Friday, April 15, 2005 4:10 AM<BR><B>To:</B> 
    isms@ietf.org<BR><B>Subject:</B> RE: [Isms] Discussion: Architecture 
    direction for ISMS<BR></FONT><BR></DIV>
    <DIV></DIV>
    <P><FONT size=2>RADIUS "Access-Accept" indicates a successful 
    authenthentication response for a user.</FONT> </P>
    <P><FONT size=2>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."".</FONT></P>
    <P><FONT size=2>RADIUS is commonly used to return policy (e.g. VACM group 
    mapping) and specific uses have been standardized.</FONT> </P>
    <P><FONT size=2>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.</FONT></P>
    <P><FONT size=2>Uri, I'm not entirely sure what you meant by "identity to 
    use" below since authentication presumes an identity was already 
    provided?</FONT></P>
    <P><FONT size=2>Martin.</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: isms-bounces@lists.ietf.org </FONT><BR><FONT size=2>&gt; [<A 
    href="mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ietf.org</A>] 
    On Behalf Of Randy Presuhn</FONT> <BR><FONT size=2>&gt; Sent: April 14, 2005 
    8:37 PM</FONT> <BR><FONT size=2>&gt; To: isms@ietf.org</FONT> <BR><FONT 
    size=2>&gt; Subject: Re: [Isms] Discussion: Architecture direction for 
    ISMS</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Hi -</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; &gt; From: "Blumenthal, Uri" 
    &lt;uri.blumenthal@intel.com&gt;</FONT> <BR><FONT size=2>&gt; &gt; To: 
    "Thierry Moreau" &lt;thierry.moreau@connotech.com&gt;</FONT> <BR><FONT 
    size=2>&gt; &gt; Cc: &lt;isms@ietf.org&gt;</FONT> <BR><FONT size=2>&gt; &gt; 
    Sent: Thursday, April 14, 2005 5:22 PM</FONT> <BR><FONT size=2>&gt; &gt; 
    Subject: RE: [Isms] Discussion: Architecture direction for ISMS</FONT> 
    <BR><FONT size=2>&gt; ...</FONT> <BR><FONT size=2>&gt; &gt; So in case of 
    RADIUS, the "access granted" should be accompanied by:</FONT> <BR><FONT 
    size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; - generated fresh 
    keying for this session (including its </FONT><BR><FONT size=2>&gt; 
    life-time);</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; - identity to use for 
    this connection (as probably nobody wants to </FONT><BR><FONT size=2>&gt; 
    &gt; configure user database on the SNMP agent :-);</FONT> <BR><FONT 
    size=2>&gt; &gt;&nbsp; - mapping of that identity onto an existing VACM 
    group.</FONT> <BR><FONT size=2>&gt; ...</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Sounds a lot like EUSM.&nbsp; (not that that'd 
    be a bad thing)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Randy</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; _______________________________________________</FONT> <BR><FONT 
    size=2>&gt; Isms mailing list</FONT> <BR><FONT size=2>&gt; 
    Isms@lists.ietf.org</FONT> <BR><FONT size=2>&gt; <A 
    href="https://www1.ietf.org/mailman/listinfo/isms" 
    target=_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C541D3.41D41FD3--


--===============1101301027==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1101301027==--



From isms-bounces@ietf.org  Fri Apr 15 12:13:35 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17608;
	Fri, 15 Apr 2005 12:13:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMTc3-0005lj-QK; Fri, 15 Apr 2005 12:24:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMTFE-0004el-7z; Fri, 15 Apr 2005 12:00:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTFB-0004dj-Hw
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 12:00:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15891
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:00:30 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTMQ-0004cj-AH
	for isms@ietf.org; Fri, 15 Apr 2005 12:08:03 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3FFvIA2021830; 
	Fri, 15 Apr 2005 15:57:19 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3FFvFKj024623; 
	Fri, 15 Apr 2005 15:57:18 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041508571723189 ; Fri, 15 Apr 2005 08:57:17 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 08:57:15 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 08:57:08 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 11:57:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 11:56:44 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9734@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVB01lEOlO2cZn2QtCSQjQcHXjXhAAAA3sw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Martin Soukup" <msoukup@nortel.com>, <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 15:57:06.0753 (UTC)
	FILETIME=[C61B9B10:01C541D3]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 142a000676f5977e1797396caab8b611
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1018691332=="
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05

This is a multi-part message in MIME format.

--===============1018691332==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C541D3.C5ACBBB7"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C541D3.C5ACBBB7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.
=20
________________________________

From: Martin Soukup [mailto:msoukup@nortel.com]=20
Sent: Friday, April 15, 2005 8:53 AM
To: Blumenthal, Uri; 'isms@ietf.org'
Subject: RE: [Isms] Discussion: Architecture direction for ISMS



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

		-----Original Message-----
		From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20
		Sent: Friday, April 15, 2005 10:58 AM
		To: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
		Subject: RE: [Isms] Discussion: Architecture direction
for ISMS
	=09
	=09
		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=3DusmSecurityName=3D"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: isms-bounces@lists.ietf.org
[mailto:isms-bounces@lists.ietf.org] On Behalf Of Martin Soukup
			Sent: Friday, April 15, 2005 4:10 AM
			To: isms@ietf.org
			Subject: RE: [Isms] Discussion: Architecture
direction for ISMS
		=09
		=09

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

			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.=20

			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.=20

			> -----Original Message-----=20
			> From: isms-bounces@lists.ietf.org=20
			> [mailto:isms-bounces@lists.ietf.org] On Behalf
Of Randy Presuhn=20
			> Sent: April 14, 2005 8:37 PM=20
			> To: isms@ietf.org=20
			> Subject: Re: [Isms] Discussion: Architecture
direction for ISMS=20
			>=20
			>=20
			> Hi -=20
			>=20
			> > From: "Blumenthal, Uri"
<uri.blumenthal@intel.com>=20
			> > To: "Thierry Moreau"
<thierry.moreau@connotech.com>=20
			> > Cc: <isms@ietf.org>=20
			> > Sent: Thursday, April 14, 2005 5:22 PM=20
			> > Subject: RE: [Isms] Discussion: Architecture
direction for ISMS=20
			> ...=20
			> > So in case of RADIUS, the "access granted"
should be accompanied by:=20
			> >=20
			> >  - generated fresh keying for this session
(including its=20
			> life-time);=20
			> >  - identity to use for this connection (as
probably nobody wants to=20
			> > configure user database on the SNMP agent
:-);=20
			> >  - mapping of that identity onto an existing
VACM group.=20
			> ...=20
			>=20
			> Sounds a lot like EUSM.  (not that that'd be a
bad thing)=20
			>=20
			> Randy=20
			>=20
			>=20
			>=20
			>=20
			>
_______________________________________________=20
			> Isms mailing list=20
			> Isms@lists.ietf.org=20
			> https://www1.ietf.org/mailman/listinfo/isms=20
			>=20
			>=20


------_=_NextPart_001_01C541D3.C5ACBBB7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1492" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D568275415-15042005><FONT face=3DArial color=3D#0000ff =

size=3D2>Martin, I don't know RADIUS well enough - but if RADIUS =
User-Name is just=20
the name that RADIUS just authenticated, then it's not what we need =
here. If=20
returned&nbsp;User-Name may be different from the original user=20
identity&nbsp;under which user asked&nbsp;RADIUS for=20
authentication/authorization - then it's OK.</FONT></SPAN></DIV>
<DIV><SPAN class=3D568275415-15042005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV>
<HR tabIndex=3D-1>
</DIV>
<DIV><FONT face=3DTahoma size=3D2><B>From:</B> Martin Soukup=20
[mailto:msoukup@nortel.com] <BR><B>Sent:</B> Friday, April 15, 2005 8:53 =

AM<BR><B>To:</B> Blumenthal, Uri; 'isms@ietf.org'<BR><B>Subject:</B> RE: =
[Isms]=20
Discussion: Architecture direction for ISMS<BR></FONT><BR></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV><SPAN class=3D600423015-15042005><FONT face=3DArial =
color=3D#0000ff size=3D2>Ah -=20
  yes. The return of this information (User-Name) in the Access-Accept =
would be=20
  supported through configuration of any standard RADIUS=20
  server.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D600423015-15042005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D600423015-15042005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>martin.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Blumenthal,=20
    Uri [mailto:uri.blumenthal@intel.com] <BR><B>Sent:</B> Friday, April =
15,=20
    2005 10:58 AM<BR><B>To:</B> Soukup, Martin [CAR:5K50:EXCH];=20
    isms@ietf.org<BR><B>Subject:</B> RE: [Isms] Discussion: Architecture =

    direction for ISMS<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D762195114-15042005><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Every existing infrastructure has its own way to identify =
its users.=20
    More often than not, these identitites do not match. One of=20
    the&nbsp;complaints wrt. SNMPv3 deployment is the fact that its set =
of=20
    identities does not [necessarily] match those other ones - and thus =
user=20
    datastore has to be filled during provisioning or configuration =
time. Thus=20
    when a RADIUS user "msoukup" request SNMP access and is=20
    authenticated+authorized, RADIUS must tell SNMP engine what identity =
to use=20
    in the SNMP traffic packets. For USM, it could be dynamically =
created entry=20
    with usmUserName=3DusmSecurityName=3D"msoukup", or a reference to an =

    already-existing one (then RADIUS should tell which, or there should =
be a=20
    rule by which the SNMP engine can figure it out by itself). For =
other=20
    systems - perhaps they can be made to just directly&nbsp;take the =
identity=20
    that RADIUS just authorized - but&nbsp;I don't think it would be any =

    easier.</FONT></SPAN></DIV><BR>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
      <HR tabIndex=3D-1>
      <FONT face=3DTahoma size=3D2><B>From:</B> =
isms-bounces@lists.ietf.org=20
      [mailto:isms-bounces@lists.ietf.org] <B>On Behalf Of </B>Martin=20
      Soukup<BR><B>Sent:</B> Friday, April 15, 2005 4:10 =
AM<BR><B>To:</B>=20
      isms@ietf.org<BR><B>Subject:</B> RE: [Isms] Discussion: =
Architecture=20
      direction for ISMS<BR></FONT><BR></DIV>
      <DIV></DIV>
      <P><FONT size=3D2>RADIUS "Access-Accept" indicates a successful=20
      authenthentication response for a user.</FONT> </P>
      <P><FONT size=3D2>The Access-Accept already returns a =
"Session-Timeout",=20
      defined as "Sets the maximum number of seconds of service to be =
provided=20
      to the user before the session terminates. This attribute value =
becomes=20
      the per-user "absolute timeout."".</FONT></P>
      <P><FONT size=3D2>RADIUS is commonly used to return policy (e.g. =
VACM group=20
      mapping) and specific uses have been standardized.</FONT> </P>
      <P><FONT size=3D2>This definitely fits well with EUSM, if =
something which=20
      can be tunneled over RADIUS can generate the key binding. This is =
why I=20
      like RADIUS.</FONT></P>
      <P><FONT size=3D2>Uri, I'm not entirely sure what you meant by =
"identity to=20
      use" below since authentication presumes an identity was already=20
      provided?</FONT></P>
      <P><FONT size=3D2>Martin.</FONT> </P>
      <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =

      size=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT><BR><FONT =
size=3D2>&gt;=20
      [<A=20
      =
href=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.iet=
f.org</A>]=20
      On Behalf Of Randy Presuhn</FONT> <BR><FONT size=3D2>&gt; Sent: =
April 14,=20
      2005 8:37 PM</FONT> <BR><FONT size=3D2>&gt; To: =
isms@ietf.org</FONT>=20
      <BR><FONT size=3D2>&gt; Subject: Re: [Isms] Discussion: =
Architecture=20
      direction for ISMS</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Hi -</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; From: "Blumenthal, Uri"=20
      &lt;uri.blumenthal@intel.com&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt; To:=20
      "Thierry Moreau" &lt;thierry.moreau@connotech.com&gt;</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; Cc: &lt;isms@ietf.org&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; Sent: Thursday, April 14, 2005 5:22 PM</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; Subject: RE: [Isms] Discussion: Architecture direction for=20
      ISMS</FONT> <BR><FONT size=3D2>&gt; ...</FONT> <BR><FONT =
size=3D2>&gt; &gt; So=20
      in case of RADIUS, the "access granted" should be accompanied =
by:</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; -=20
      generated fresh keying for this session (including its =
</FONT><BR><FONT=20
      size=3D2>&gt; life-time);</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; - identity=20
      to use for this connection (as probably nobody wants to =
</FONT><BR><FONT=20
      size=3D2>&gt; &gt; configure user database on the SNMP agent =
:-);</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;&nbsp; - mapping of that identity onto =
an=20
      existing VACM group.</FONT> <BR><FONT size=3D2>&gt; ...</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Sounds a lot like =
EUSM.&nbsp;=20
      (not that that'd be a bad thing)</FONT> <BR><FONT size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; Randy</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
      _______________________________________________</FONT> <BR><FONT=20
      size=3D2>&gt; Isms mailing list</FONT> <BR><FONT size=3D2>&gt;=20
      Isms@lists.ietf.org</FONT> <BR><FONT size=3D2>&gt; <A=20
      href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
      =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C541D3.C5ACBBB7--


--===============1018691332==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1018691332==--



From isms-bounces@ietf.org  Fri Apr 15 12:40:09 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20042;
	Fri, 15 Apr 2005 12:40:09 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMU1m-0007Ka-1K; Fri, 15 Apr 2005 12:50:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMTnY-0003LI-F1; Fri, 15 Apr 2005 12:36:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTnW-0003L2-Fn
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 12:36:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19680
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:35:59 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMTxj-0007Dh-KZ
	for isms@ietf.org; Fri, 15 Apr 2005 12:46:37 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3FGZpsC023334; 
	Fri, 15 Apr 2005 09:35:51 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3FGZo7E009048;
	Fri, 15 Apr 2005 09:35:50 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3FGZof2009045; Fri, 15 Apr 2005 09:35:50 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 15 Apr 2005 09:35:50 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Randy Presuhn <randy_presuhn@mindspring.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <001201c54153$2ec23e20$7f1afea9@oemcomputer>
Message-ID: <Pine.LNX.4.10.10504150931190.4466-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

HI Randy,

On Thu, 14 Apr 2005, Randy Presuhn wrote:

> Hi -
> 
> > From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
> > To: "Thierry Moreau" <thierry.moreau@connotech.com>
> > Cc: <isms@ietf.org>
> > Sent: Thursday, April 14, 2005 5:22 PM
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> ...
> > 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.
> ...
> 
> Sounds a lot like EUSM.  (not that that'd be a bad thing)
> 
> Randy

Would you explain your statement "Sounds a lot like EUSM" because
EUSM didn't invent this, nor is it exclusive to EUSM, nor is
it key unique characteristic to EUSM that differentiates
it from other approaches. 

Thanks,
/david t. perkins


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 12:53:43 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20938;
	Fri, 15 Apr 2005 12:53:43 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMUEu-0008BO-1s; Fri, 15 Apr 2005 13:04:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMTrm-000457-HR; Fri, 15 Apr 2005 12:40:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTrl-00044w-9D
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 12:40:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20081
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:40:22 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMU1z-0007Kp-Ks
	for isms@ietf.org; Fri, 15 Apr 2005 12:51:00 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3FGdksC024222; 
	Fri, 15 Apr 2005 09:39:46 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3FGdjVs010078;
	Fri, 15 Apr 2005 09:39:45 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3FGditr010074; Fri, 15 Apr 2005 09:39:45 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 15 Apr 2005 09:39:44 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Martin Soukup <msoukup@nortel.com>
Subject: RE: [Isms] SSH / Reusability / etc
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B39@zcarhxm2.corp.nortel.com>
Message-ID: <Pine.LNX.4.10.10504150938580.4466-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17

HI,

On Fri, 15 Apr 2005, Martin Soukup wrote:
> I absolutely agree with the sentiment, whether Sam agrees or not.
> 
> Martin.
> 
> > -----Original Message-----
> > From: Eliot Lear [mailto:lear@cisco.com] 
> > Sent: April 15, 2005 4:34 AM
> > To: Sam Hartman
> > Cc: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
> > Subject: Re: [Isms] SSH / Reusability / etc
> > 
> > 
> > Sam,
> > 
> > If I read your messages your are saying that it is okay to 
> > explore use 
> > of the ssh protocol, but that use of just the keys wouldn't 
> > float your 
> > boat.  Is that a fair summary?
> > 
> > Eliot

Martin, would you explain your reasoning.

Thanks,
/david t. perkins


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 12:58:22 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21316;
	Fri, 15 Apr 2005 12:58:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMUJP-0008R4-Hz; Fri, 15 Apr 2005 13:08:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMTwW-000532-BR; Fri, 15 Apr 2005 12:45:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMTwV-00052x-FV
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 12:45:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20483
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:45:16 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMU6h-0007ko-UD
	for isms@ietf.org; Fri, 15 Apr 2005 12:55:54 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id DB0B3E0063; Fri, 15 Apr 2005 12:45:11 -0400 (EDT)
To: Eliot Lear <lear@cisco.com>
Subject: Re: [Isms] SSH / Reusability / etc
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
	<tsl64ypdpvh.fsf@cz.mit.edu> <425F7C80.8050007@cisco.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 15 Apr 2005 12:45:11 -0400
In-Reply-To: <425F7C80.8050007@cisco.com> (Eliot Lear's message of "Fri, 15
	Apr 2005 10:34:08 +0200")
Message-ID: <tslis2of0q0.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

>>>>> "Eliot" == Eliot Lear <lear@cisco.com> writes:

    Eliot> Sam, If I read your messages your are saying that it is
    Eliot> okay to explore use of the ssh protocol, but that use of
    Eliot> just the keys wouldn't float your boat.  Is that a fair
    Eliot> summary?

no.  It is OK to explore use of the ssh keys, although I'm personally
against it.  As an AD, you'd need to get the secsh wg's cooperation.

Re use of the ssh protocol is clearly OK if you can make it work.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 13:03:22 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21576;
	Fri, 15 Apr 2005 13:03:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMUOB-0000GU-LZ; Fri, 15 Apr 2005 13:13:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMU7m-0006gU-CD; Fri, 15 Apr 2005 12:56:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMU7j-0006g8-SA
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 12:56:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21157
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:56:53 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUHy-0008Os-G3
	for isms@ietf.org; Fri, 15 Apr 2005 13:07:30 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 93D5FE0063; Fri, 15 Apr 2005 12:56:51 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA93FE@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 15 Apr 2005 12:56:51 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA93FE@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Thu, 14 Apr 2005 17:59:13 -0400")
Message-ID: <tsl64yof06k.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

    Blumenthal,> Please see below.
>>>>> "Blumenthal" == Blumenthal, Uri <uri.blumenthal@intel.com>
    Blumenthal,> writes:

    Blumenthal> Please point me at the reference in the SNMPv3 RFCs
    Blumenthal> that says anything about credentials that SNMP engine
    Blumenthal> *itself* has - as opposite to storing credentials for
    Blumenthal> *users* that are allowed to talk to this engine.

    >> I think you are perhaps a bit too focused on USM here.

    Blumenthal,> Not USM as much as SNMPv3 in general. But your point
    Blumenthal,> is taken.

    >> The premis of this working group is that people have
    >> infrastructure today that has credentials.  They would like to
    >> use that infrastructure to secure SNMP engines.  They have
    >> described several such infrastructures.

    Blumenthal,> It's the relation between those infrastructures and
    Blumenthal,> SNMP identities, and mapping to SNMP Access Control
    Blumenthal,> that is missing.

Yes, I agree that is part of a solution to the charter of this working
group.  You seem to believe that it will be the hardest part of the
solution/the part that drives a lot of other decisions.  I'm not sure
I would go that far.  I do agree it needs to be done and I do agree
some propoproposals in this WG have not focused on that at all.

    >> In these infrastructures--at least in the infrastructures I
    >> mentioned in my previous message--an engine acting in one of
    >> these infrastructures has a natural credential to use.

    Blumenthal,> I must have missed that message. What infrastructure
    Blumenthal,> is that, and what credential is natural for SNMP
    Blumenthal,> engine in it?

I can go dig up the message if you like, but I'd rather just reiterate
the infrastructures I was discussing.

In the ssh case, I'd expect one SNMP engine to have a host key and the
other to be acting as a user and thus have some username/password,
public key or something like that.

For Kerberos, I'd expect one SNMP engine to have a long-term service
key, and the other to have a TGT or something like that.

In the RADIUS case, I'd expect one SNMP engine to have a shared key
with the RADIUS infrastructure and the other to have a username and
password.  This case is actually a bit problematic for the
notification example.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 13:28:07 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24014;
	Fri, 15 Apr 2005 13:28:07 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMUmD-0001il-AI; Fri, 15 Apr 2005 13:38:45 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMUXv-0002op-6p; Fri, 15 Apr 2005 13:23:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUXt-0002oW-7Z
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 13:23:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23524
	for <isms@ietf.org>; Fri, 15 Apr 2005 13:23:54 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUi5-0001Ru-Rs
	for isms@ietf.org; Fri, 15 Apr 2005 13:34:32 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3FHNksC001712; 
	Fri, 15 Apr 2005 10:23:46 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3FHNjXU023390;
	Fri, 15 Apr 2005 10:23:45 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3FHNir5023382; Fri, 15 Apr 2005 10:23:45 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 15 Apr 2005 10:23:44 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9734@pysmsx401.amr.corp.intel.com>
Message-ID: <Pine.LNX.4.10.10504151001260.4466-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407

HI,

In URI's message below, he has the the example
"For USM, it could be dynamically created entry with
 usmUserName=usmSecurityName="msoukup" ..."

This would not work! 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.
The value of msgUserName name would be temporal, lasting
only the duration of the session, but also unique during
its existance.

Regards,
/david t. perkins

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:msoukup@nortel.com] 
> Sent: Friday, April 15, 2005 8:53 AM
> To: Blumenthal, Uri; 'isms@ietf.org'
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> 
> 	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:uri.blumenthal@intel.com] 
> 		Sent: Friday, April 15, 2005 10:58 AM
> 		To: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
> 		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.
> 
> 
> ________________________________
> 
> 			From: isms-bounces@lists.ietf.org
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Martin Soukup
> 			Sent: Friday, April 15, 2005 4:10 AM
> 			To: isms@ietf.org
> 			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. 
> 
> 			> -----Original Message----- 
> 			> From: isms-bounces@lists.ietf.org 
> 			> [mailto:isms-bounces@lists.ietf.org] On Behalf
> Of Randy Presuhn 
> 			> Sent: April 14, 2005 8:37 PM 
> 			> To: isms@ietf.org 
> 			> Subject: Re: [Isms] Discussion: Architecture
> direction for ISMS 
> 			> 
> 			> 
> 			> Hi - 
> 			> 
> 			> > From: "Blumenthal, Uri"
> <uri.blumenthal@intel.com> 
> 			> > To: "Thierry Moreau"
> <thierry.moreau@connotech.com> 
> 			> > Cc: <isms@ietf.org> 
> 			> > Sent: Thursday, April 14, 2005 5:22 PM 
> 			> > Subject: RE: [Isms] Discussion: Architecture
> direction for ISMS 
> 			> ... 
> 			> > 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. 
> 			> ... 
> 			> 
> 			> Sounds a lot like EUSM.  (not that that'd be a
> bad thing) 
> 			> 
> 			> Randy 
> 			> 
> 			> 
> 			> 
> 			> 
> 			>
> _______________________________________________ 
> 			> Isms mailing list 
> 			> Isms@lists.ietf.org 
> 			> https://www1.ietf.org/mailman/listinfo/isms 
> 			> 
> 			> 
> 
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 13:36:50 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24964;
	Fri, 15 Apr 2005 13:36:50 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMUua-0002H2-TI; Fri, 15 Apr 2005 13:47:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMUi7-0004qf-Fv; Fri, 15 Apr 2005 13:34:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUi6-0004qH-C5
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 13:34:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24727
	for <isms@ietf.org>; Fri, 15 Apr 2005 13:34:29 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUsK-00029V-Aw
	for isms@ietf.org; Fri, 15 Apr 2005 13:45:05 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 23620E0077; Fri, 15 Apr 2005 13:34:24 -0400 (EDT)
To: "Martin Soukup" <msoukup@nortel.com>
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B37@zcarhxm2.corp.nortel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 15 Apr 2005 13:34:24 -0400
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B37@zcarhxm2.corp.nortel.com>
	(Martin Soukup's message of "Fri, 15 Apr 2005 07:10:03 -0400")
Message-ID: <tslaco0djvj.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: isms@ietf.org
Subject: [Isms] RADIUS is not a trusted third party
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007

>>>>> "Martin" == Martin Soukup <msoukup@nortel.com> writes:

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

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

This only tells the SNMP engine talking to the RADIUS server the
timeout.  You need to tell the other side of the exchange the timeout
too.

Remember that RADIUS is a callout service; it is not a trusted third
party.  In other words, in a particular SNMP authentication, only one
of the parties will know that RADIUS is being used.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 13:54:27 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26794;
	Fri, 15 Apr 2005 13:54:27 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVBe-0003OZ-Ib; Fri, 15 Apr 2005 14:05:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMUcr-0003pq-AD; Fri, 15 Apr 2005 13:29:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUco-0003pe-Cu
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 13:29:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24078
	for <isms@ietf.org>; Fri, 15 Apr 2005 13:29:01 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUn2-0001lV-7o
	for isms@ietf.org; Fri, 15 Apr 2005 13:39:37 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 18C10E0063; Fri, 15 Apr 2005 13:28:55 -0400 (EDT)
To: Thierry Moreau <thierry.moreau@connotech.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA9313@pysmsx401.amr.corp.intel.com>
	<20050414203701.GB8469@boskop.local> <425F0218.4080908@connotech.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 15 Apr 2005 13:28:55 -0400
In-Reply-To: <425F0218.4080908@connotech.com> (Thierry Moreau's message of
	"Thu, 14 Apr 2005 19:51:52 -0400")
Message-ID: <tslekdcdk4o.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

>>>>> "Thierry" == Thierry Moreau <thierry.moreau@connotech.com> writes:

    Thierry> Juergen Schoenwaelder wrote:

    >> 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?

    Thierry> RADIUS?

    Thierry> RADIUS with an "implementation-specific" attribute in an
    Thierry> Access-Request packet to indicate to the RADIUS server
    Thierry> that some "Authenticate Only" service type request is a
    Thierry> request to a) authenticate the end- user, b) validate
    Thierry> that the end-user is allowed SNMPv3 agent registration,
    Thierry> and c) convey the required keying information to the NAS
    Thierry> in the network device, in an implementation-specific
    Thierry> attribute to the RADIUS Access-Accept packet.

This sounds a lot like inventing Kerberos over RADIUS.  I can't say
that I'm thrilled with that but I'd need to understand exactly what
you're proposing better.

I mostly invision RADIUS being used between the SNMP engine and the
RADIUS server to confirm the authentication and get key material for
some other OBK protocol.  In particular if more than one party in an
exchange is directly talking to a RADIUS server, you are probably
doing something wrong.

OBK solutions could be built on top of SASL, TLS, SSH, GSS, DTLS or
something invented by this working group.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 13:59:08 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27078;
	Fri, 15 Apr 2005 13:59:08 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVGC-0003gC-6Y; Fri, 15 Apr 2005 14:09:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMV1B-00008x-Lq; Fri, 15 Apr 2005 13:54:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMV1A-00008P-1D
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 13:54:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26787
	for <isms@ietf.org>; Fri, 15 Apr 2005 13:54:11 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVBO-0003O5-IN
	for isms@ietf.org; Fri, 15 Apr 2005 14:04:47 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 15 Apr 2005 10:54:02 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3FHrZiG012651
	for <isms@ietf.org>; Fri, 15 Apr 2005 10:53:59 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 15 Apr 2005 10:53:57 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C541E4.185FC77D"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Fri, 15 Apr 2005 10:53:55 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F68E@xmb-sjc-22e.amer.cisco.com>
X-MS-Has-Attach: yes
Thread-Topic: YAAP (Yet Another Architecture Proposal) - Localized PSK Auth
Thread-Index: AcVB5BehP0JzTBlnSFyxyR8z4rVqMQ==
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 17:53:57.0447 (UTC)
	FILETIME=[18CE9D70:01C541E4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451
Subject: [Isms] YAAP (Yet Another Architecture Proposal) - Localized PSK Auth
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90

This is a multi-part message in MIME format.

------_=_NextPart_001_01C541E4.185FC77D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,
=20
I am new to this ISMS mailing list and would like to share some thoughts
that I had recently about SNMPv3.  Attached please find a proposal to
use localized pre-shared keys for SNMPv3 authentication.  This is a
preliminary draft so sorry if some details are missing. =20
=20
The main points of the proposal are:
=20
1. Decouple authentication from data integrity and confidentiality
2. Data integrity and confidentiality are to be done at the transport
layer (e.g. TLS), similar to the TMSM proposal.
3. Authentication to be done at SNMP application level (on top of a
secure transport)
4. <user ID+password+snmpEngine ID> are used to generate localized
pre-shared keys (LPSK), which are then used to certify the credentials
of the users as well as SNMP devices.
5. A PSK protocol (such as SRP) over a secure transport (e.g. TLS) uses
LPSK-based credentials to authenticate users and devices.  No external
auth infrastructure is needed (other than one to configure users and/or
community strings.)
=20
This proposal is an abstract model and does not specify any protocol
selections.  I hope that it can be used as a starting point for a new
SNMPv3 authentication model that is secure, simple, and flexible.  Your
comments and suggestions will be greatly appreciated.
=20
I'd like to thank Kaushik Narayan and Keith McCloghrie for their early
comments on the proposal.  (This is not to say that they endorse it.)
=20
Khanh =20
=20
=20
=20
=20

------_=_NextPart_001_01C541E4.185FC77D
Content-Type: text/plain;
	name="LPSK.txt"
Content-Description: LPSK.txt
Content-Disposition: attachment;
	filename="LPSK.txt"
Content-Transfer-Encoding: base64

TG9jYWxpemVkIFByZS1TaGFyZWQgS2V5IEF1dGhlbnRpY2F0aW9uIChMUFNLKSBmb3IgU05NUHYz
DQoJCQkJCQkNCktoYW5oIE5ndXllbiAoa2hhbmh2bkBjaXNjby5jb20pDQpBcHIgMTQsIDIwMDUN
Cg0KDQoxLiBJbnRyb2R1Y3Rpb24NCi0tLS0tLS0tLS0tLS0tLQ0KDQpTZWN1cmluZyBhIGNvbW11
bmljYXRpb24gc3lzdGVtIGdlbmVyYWxseSByZXF1aXJlcyB0aHJlZSBtYWluIHNlcnZpY2VzOg0K
LQlBdXRoZW50aWNhdGlvbg0KLQlEYXRhIENvbmZpZGVudGlhbGl0eSAocHJpdmFjeSkNCi0JRGF0
YSBJbnRlZ3JpdHkgKG1lc3NhZ2UgYXV0aGVudGljYXRpb24pDQoNClRoaXMgcHJvcG9zYWwgbGlt
aXRzIGl0cyBzY29wZSB0byB0aGUgYXV0aGVudGljYXRpb24gc2VydmljZSBmb3IgU05NUHYzLg0K
VGhlIG90aGVyIHR3byBzZXJ2aWNlcywgY29uZmlkZW50aWFsaXR5IGFuZCBkYXRhIGludGVncml0
eSwgY2FuIGJlIA0KcHJvdmlkZWQgYnkgYSBzZWN1cmUgdHJhbnNwb3J0IGxheWVyLCBzdWNoIGFz
IFRTTCBvciBTU0gsIGFzIGRlc2NyaWJlZCANCmluIHRoZSBUTVNNIHByb3Bvc2FsLg0KDQpJbiB0
aGlzIHByb3Bvc2FsLCBTTk1QIGVudGl0aWVzIGFyZSBhdXRoZW50aWNhdGVkIHVzaW5nIHRoZSBs
b2NhbGl6ZWQgDQpwcmUtc2hhcmVkIGtleSAoTFBTSykgbWV0aG9kLiAgVGhlIHVzZXIgcGFzc3dv
cmRzIG9yIGNvbW11bml0eSBzdHJpbmdzIA0KYXJlIHVzZWQgdG8gZ2VuZXJhdGUgYXV0aGVudGlj
YXRpb24gY3JlZGVudGlhbHMgZm9yIG5vdCBvbmx5IHVzZXJzIGJ1dCANCmFsc28gU05NUCBlbmdp
bmVzLiAgTm8gZXh0ZXJuYWwgaW5mcmFzdHJ1Y3R1cmUgKGUuZy4gY2VydGlmaWNhdGUgDQptYW5h
Z2VtZW50LCBrZXkgZGlzdHJpYnV0aW9uIHNlcnZlcnMpIGlzIHJlcXVpcmVkLiAgDQoNCg0KMi4g
T2JqZWN0aXZlcw0KLS0tLS0tLS0tLS0tLQ0KDQpUaGUgcHJvcG9zZWQgYXJjaGl0ZWN0dXJlIGFp
bXMgYXQgdGhlIGZvbGxvd2luZyBvYmplY3RpdmVzOg0KDQotIEhpZ2hseSBTZWN1cmUNCi0gU2lt
cGxlIHRvIGltcGxlbWVudA0KLSBFYXN5IHRvIGRlcGxveSBhbmQgb3BlcmF0ZSwgZWFzeSB0byBt
aWdyYXRlIGZyb20gU05NUHYxIGFuZCBVU00NCi0gU3VwcG9ydCBtdWx0aXBsZSB0cmFuc3BvcnQg
c2VjdXJpdHkgb3B0aW9ucw0KLSBTZWxmLWNvbnRhaW5lZCwgZG8gbm90IHJlcXVpcmUgZXh0ZXJu
YWwgaW5mcmFzdHJ1Y3R1cmUgb3RoZXIgdGhhbg0KICBiYXNpYyBuZXR3b3JrIHNlcnZpY2VzDQot
IENvbXBhdGlibGUgd2l0aCBib3RoIHZpZXctYmFzZWQgW1ZBQ01dIGFuZCBjb21tdW5pdHktYmFz
ZWQgYWNjZXNzIA0KICBjb250cm9sIG1vZGVscw0KLSBTdXBwb3J0IENlbnRyYWxpemVkIEFBQQ0K
DQoNCjMuIFNlcGFyYXRpbmcgQXV0aGVudGljYXRpb24gZnJvbSBDb25maWRlbnRpYWxpdHkgYW5k
IERhdGEgSW50ZWdyaXR5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPZiB0aGUgdGhyZWUgYmFzaWMgc2VjdXJp
dHkgc2VydmljZXMsIGF1dGhlbnRpY2F0aW9uIGlzIGFib3V0IHRoZSANCmNvbW11bmljYXRpbmcg
cGFydGllcyAodXNlcnMsIGRldmljZXMsIGV0Yy4pLCB3aGlsZSBjb25maWRlbnRpYWxpdHkgYW5k
IA0KZGF0YSBpbnRlZ3JpdHkgYXJlIGFib3V0IHRoZSBjb21tdW5pY2F0ZWQgZGF0YSAoYml0cyBh
bmQgYnl0ZXMpLiAgIA0KDQpBdXRoZW50aWNhdGlvbiBpcyB2ZXJ5IGFwcGxpY2F0aW9uLXNwZWNp
ZmljLiAgVGhlIG5hdHVyZXMgb2YgdGhlIGVudGl0aWVzDQp0byBiZSBhdXRoZW50aWNhdGVkIHZh
cnkgZnJvbSBvbmUgYXBwbGljYXRpb24gdG8gYW5vdGhlci4gIE9uIHRoZSBvdGhlciANCmhhbmQs
IGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0YSBpbnRlZ3JpdHkgYXJlIG1vcmUgZ2VuZXJpYyBzZXJ2
aWNlcy4gIA0KQXBwbGljYXRpb25zIG9mdGVuIHNoYXJlIHRoZSBzYW1lIGJhc2ljIG5lZWRzIHRo
YXQgdGhlIGJpdHMgYW5kIGJ5dGVzIA0KaW4gdHJhbnNpdCBtdXN0IG5vdCBiZSByZWFkIChjb25m
aWRlbnRpYWxpdHkpIG9yIGFsdGVyZWQgKGludGVncml0eSkgYnkgDQpvdXRzaWRlcnMuICANCg0K
QmVjYXVzZSBvZiB0aGUgYWJvdmUgZGlmZmVyZW5jZSwgaXQgbWF5IGJlIHVzZWZ1bCB0byBkaXZp
ZGUgKGFic3RyYWN0bHkpDQpTTk1QdjMgc2VjdXJpdHkgc3lzdGVtIGludG8gdHdvIHN1Yi1tb2R1
bGVzOiAoMSkgYXV0aGVudGljYXRpb24gYW5kIA0KKDIpIGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0
YSBpbnRlZ3JpdHkuICBJbiB0aGlzIHByb3Bvc2FsLCBhdXRoZW50aWNhdGlvbg0Kd2lsbCBiZSBh
biBpbnRlZ3JhdGVkIHBhcnQgb2YgU05NUCBzZWN1cml0eSBzeXN0ZW0sIHdoaWxlIGNvbmZpZGVu
dGlhbGl0eQ0KYW5kIGRhdGEgaW50ZWdyaXR5IHdpbGwgYmUgaGFuZGxlZCBieSB0aGUgdHJhbnNw
b3J0IGxheWVyLg0KICANCkJ5IG1vZHVsYXJpemluZyB0aGUgU05NUHYzIHNlY3VyaXR5IHN5c3Rl
bSB0aGlzIHdheSwgd2UgY2FuIGhhdmUgdGhlIA0KZmxleGliaWxpdHkgdG8gbWVldCB0aGUgc3Bl
Y2lmaWMgbmVlZHMgb2YgdGhlIFNOTVAgYXBwbGljYXRpb24gd2hpbGUgDQptYXhpbWl6aW5nIHRo
ZSB1c2Ugb2YgY29tbW9uLCBvZmYtdGhlLXNoZWx2ZSBjb21wb25lbnRzIHN1Y2ggYXMgVExTL1NT
SC4NClRoZSBzYW1lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUgdXNlZCB3aXRoIGRpZmZl
cmVudCB0cmFuc3BvcnQgdHlwZXMNCnByb3ZpZGluZyBkaWZmZXJlbnQgbGV2ZWxzIG9mIGRhdGEg
cHJvdGVjdGlvbi4NCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICBTTk1QdjMgU2VjdXJpdHkgU3lz
dGVtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfA0KICAgfCAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgIHwgIHwgICAgICAgICAgICAgICAgTFBTSyBBdXRoZW50
aWNhdGlvbiBTZXJ2aWNlICAgICAgICAgICAgICAgICB8ICB8DQogICB8ICArLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgfA0KICAg
fCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgIHwNCiAgIHwgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0tLS0t
LS0tKyAgKy0tLS0tLS0tLS0tLS0tLS0rICB8DQogICB8ICB8IFNlY3VyZSAgICAgICAgICAgIHwg
IHwgU2VjdXJlICAgICAgICAgIHwgIHwgSW5zZWN1cmUgICAgICAgfCAgfA0KICAgfCAgfCBDb25u
ZWN0bi1vcmllbnRlZCB8ICB8IENvbm5lY3Rpb25sZXNzICB8ICB8IFRyYW5zcG9ydCAgICAgIHwg
IHwNCiAgIHwgIHwgVHJhbnNwb3J0ICAgICAgICAgfCAgfCBUcmFuc3BvcnQgICAgICAgfCAgfCAo
VURQLFRDUCkgICAgICB8ICB8DQogICB8ICB8IChUTFMvU1NIKSAgICAgICAgIHwgIHwgKFNlc3Np
b24tYmFzZWQpIHwgIHwgICAgICAgICAgICAgICAgfCAgfA0KICAgfCAgKy0tLS0tLS0tLS0tLS0t
LS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgIHwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQoNCjQuIExvY2FsaXplZCBQcmUtU2hhcmVkIEtl
eSAoTFBTSykgQXV0aGVudGljYXRpb24gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoaXMgYXJjaGl0ZWN0dXJlIHByb3Bvc2VzIGEgc2VsZi1j
b250YWluZWQgYXV0aGVudGljYXRpb24gZnJhbWV3b3JrIA0KYmFzZWQgb24gdGhlIFBTSyBtZXRo
b2QuIE5vIGV4dGVybmFsIGNyZWRlbnRpYWwgaW5mcmFzdHJ1Y3R1cmUgaXMgbmVlZGVkDQoob3Ro
ZXIgdGhhbiBvbmUgdG8gY29uZmlndXJlIHVzZXJzIGFuZC9vciBjb21tdW5pdHkgc3RyaW5ncy4p
ICBUaGUgdXNlciANCnBhc3N3b3JkcyBhbmQvb3IgY29tbXVuaXR5IHN0cmluZ3MgYXJlIHVzZWQg
dG8gZ2VuZXJhdGUgdGhlIHByZS1zaGFyZWQgDQprZXlzIHRoYXQgYXV0aGVudGljYXRlcyBub3Qg
b25seSB1c2VycyBidXQgYWxzbyBTTk1QIGVuZ2luZXMuDQoNClNlY3VyZSB0cmFuc3BvcnRzIHN1
Y2ggYXMgVExTIG9yIFNTSCBoYXZlIG1hbnkgYnVpbHQtaW4gYXV0aGVudGljYXRpb24gDQptZXRo
b2RzOiBwdWJsaWMta2V5IGNlcnRpZmljYXRlcywgS2VyYmVyb3MsIGhvc3QgZmlsZXMsIGV0Yy4g
IFRoZSBtYWluIA0KZHJhd2JhY2sgb2YgdGhlc2UgbWV0aG9kcyBpcyB0aGF0IHRoZXkgcmVxdWly
ZSBleHRlcm5hbCBpbmZyYXN0cnVjdHVyZSANCihlLmcuIGNlcnRpZmljYXRlIGF1dGhvcml0eSwg
Y2VudHJhbGl6ZWQga2V5IGRpc3RyaWJ1dGlvbiBjZW50ZXIsIGV0Yy4pIA0KdGhhdCBuZWVkIHNp
Z25pZmljYW50IGVmZm9ydHMgdG8gZGVwbG95IGFuZCBvcGVyYXRlLg0KDQpQcmUtc2hhcmVkIGtl
eSBpcyBjb21tb25seSB1c2VkIHRvIHBlcmZvcm0gbXV0dWFsIGF1dGhlbnRpY2F0aW9uLiAgVGhl
IA0KbWFqb3Igd2Vha25lc3Mgb2YgY29udmVudGlvbmFsIFBTSyBhdXRoZW50aWNhdGlvbiBpcyB0
aGF0IHRoZSBzaGFyZWQga2V5DQppcyBrbm93biBieSBtYW55IGVudGl0aWVzLiAgSW4gU05NUCBl
bnZpcm9ubWVudHMsIHdoaWNoIGNhbiBoYXZlIGxhcmdlIA0KbnVtYmVycyBvZiBjb21tdW5pY2F0
aW5nIGVudGl0aWVzLCB0aGlzIGNhbiBiZSBhIHByb2JsZW06IGlmIG9uZSBlbnRpdHkgDQppcyBj
b21wcm9taXNlZCAoZS5nLiBhIGRldmljZSBpcyBzdG9sZW4pLCB0aGUgd2hvbGUgc3lzdGVtIG1h
eSBiZSANCnZ1bG5lcmFibGUuDQoNClRvIGFkZHJlc3MgdGhhdCBpc3N1ZSwgdGhpcyBwcm9wb3Nh
bCB1c2VzIGEgbG9jYWxpemF0aW9uIHNjaGVtZSBzaW1pbGFyIA0KdG8gdGhhdCBvZiB0aGUgVVNN
IG1vZGVsLiAgVGhlIHVzZXIgSUQsIHVzZXIgcGFzc3dvcmQsIGFuZCBTTk1QIEVuZ2luZSBJRA0K
YXJlIGNvbWJpbmVkIHRvIGdlbmVyYXRlIGEgbG9jYWxpemVkIFBTSy4gIFRoZSBMUFNLIHZhbHVl
cywgbm90IHRoZSANCnBhc3N3b3JkcywgYXJlIHN0b3JlZCBpbiB0aGUgZGV2aWNlIGFuZCBzZXJ2
ZSBhcyBib3RoIHRoZSBkZXZpY2UgDQpjcmVkZW50aWFsIChmb3IgZGV2aWNlIGF1dGhlbnRpY2F0
aW9uKSBhcyB3ZWxsIGFzIHRoZSBwYXNzd29yZCANCmF1dGhlbnRpY2F0b3IgKGZvciB1c2VyIGF1
dGhlbnRpY2F0aW9uLikgIFNwZWNpZmljYWxseSwgdGhlIExQU0sgdmFsdWUgDQppcyBnZW5lcmF0
ZWQgYXMgYmVsb3c6DQoNCglMUFNLID0gTUQ1KHVzZXJJRCArIE1ENSh1c2VyIHBhc3N3b3JkKSAr
IHNubXBFbmdpbmVJRCkNCg0KVGhlIHJlYXNvbiB0aGUgaW5uZXIgTUQ1IGlzIHVzZWQgaXMgdG8g
cHJvdGVjdCB0aGUgcGFzc3dvcmQgZHVyaW5nIHVzZXIgDQpjb25maWd1cmF0aW9uLiAgU2VlIHNl
Y3Rpb24gNyAoQ29uZmlndXJhdGlvbnMpIGJlbG93IGZvciBtb3JlIGRldGFpbHMuDQpNRDUgaXMg
dXNlZCBhcyBhbiBleGFtcGxlLiAgQW5vdGhlciBzZWN1cmUgaGFzaCBmdW5jdGlvbiBzdWNoIGFz
IFNIQSBjYW4NCmFsc28gYmUgdXNlZC4NCg0KT25jZSBMUFNLIHZhbHVlcyBhcmUgZGVmaW5lZCwg
dGhleSBjYW4gYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIGEgUFNLIA0KcHJvdG9jb2wgdG8g
bXV0dWFsbHkgYXV0aGVudGljYXRlIHVzZXJzIGFuZCBkZXZpY2VzLiAgVGhlcmUgYXJlIG1hbnkg
UFNLDQphdXRoZW50aWNhdGlvbiBtZXRob2RzLiAgVGhlIFNlY3VyZSBSZW1vdGUgUGFzc3dvcmQg
KFNSUCkgcHJvdG9jb2wgaXMgDQpvbmUgb2YgdGhlbS4gIFNSUCBkb2VzIG5vdCBsb2NhbGl6ZSB0
aGUgc2hhcmVkIGtleSwgc28gdGhlIGxvY2FsaXphdGlvbiANCm1lY2hhbmlzbSBhYm92ZSB3aWxs
IG5lZWQgdG8gYmUgaW1wbGVtZW50ZWQgc2VwYXJhdGVseS4gIFNSUCBpcyBhbiANCmFic3RyYWN0
IHByb3RvY29scyB3aXRoIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucy4gIFRoZXJlIGlzIGFuIElG
VEYgDQpwcm9wb3NhbCB0byBhZGQgU1JQIGF1dGhlbnRpY2F0aW9uIHRvIFRTTCBbVExTIFNSUF0u
ICBCdXQgdG8gYXZvaWQgDQpkZXBlbmRlbmN5IG9uIGEgc3BlY2lmaWMgdHJhbnNwb3J0LCBpdCBt
YXkgYmUgZGVzaXJhYmxlIHRvIHVzZSBhbiANCmFwcGxpY2F0aW9uLWxldmVsIGltcGxlbWVuYXRp
b24gb2YgU1JQLiAgT25lIHN1Y2ggYWx0ZXJuYXRpdmUgaXMgdG8gDQppbXBsZW1lbnQgU1JQIHVz
aW5nIHNubXBHZXQgYW5kL29yIHNubXBTZXQgbWVzc2FnZXMuICBBIHNtYWxsIE1JQiBjYW4gYmUN
CmRlZmluZWQgZm9yIHRoaXMgcHVycG9zZS4NCg0KDQo1LiBJbnRlZ3JhdGlvbiB3aXRoIHRoZSBU
cmFuc3BvcnQgTGF5ZXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQpBcyBtZW50aW9uZWQgZWFybGllciwgdGhpcyBhcmNoaXRlY3R1cmUgcmVsaWVzIG9uIHRoZSB0
cmFuc3BvcnQgbGF5ZXIgDQp0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0YSBpbnRl
Z3JpdHkuICBUaGUgcHJvY2VzcyBvZiANCmF1dGhlbnRpY2F0aW5nIGEgU05NUCBjb21tdW5pY2F0
aW9uIHNlc3Npb24gb3ZlciBhIHNlY3VyZSBjb25uZWN0aW9uLQ0Kb3JpZW50ZWQgdHJhbnNwb3J0
IGlzIGRlc2NyaWJlZCBiZWxvdy4gIFRMUyBpcyB1c2VkIGFzIGFuIGV4YW1wbGUsIA0KYnV0IGFu
b3RoZXIgdHJhbnNwb3J0IHN1Y2ggYXMgU1NIIGNhbiBhbHNvIGJlIHVzZWQuDQoNCjEuVGhlIHR3
byBlbnRpdGllcyAoU05NUCB1c2VyICYgbWFuYWdlZCBkZXZpY2UpIHBlcmZvcm0gVExTIGtleSBl
eGNoYW5nZQ0KICAoRC1IIG9yIFJTQSkgYW5kIG90aGVyIHBhcmFtZXRlciBuZWdvdGlhdGlvbnMu
DQoyLkEgVExTIGNvbm5lY3Rpb24gKHdpdGggbm9BdXRoKSBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVu
IHRoZSB0d28gZW50aXRpZXMuDQogIFRoZSBUTFMgY29ubmVjdGlvbiBpcyBzZWN1cmUgaW4gdGVy
bXMgb2YgY29uZmlkZW50aWFsaXR5IGFuZCBkYXRhIA0KICBpbnRlZ3JpdHkgKGkuZS4gbm8gdGhp
cmQgcGFydHkgY2FuIHJlYWQgb3IgYWx0ZXIgdGhlIGRhdGEgdHJhbnNtaXR0ZWQpLA0KICBidXQg
dGhlIHR3byBlbnRpdGllcyBoYXZlIG5vdCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB5ZXQuDQoz
LlRoZSB0d28gZW50aXRpZXMgYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgdXNpbmcgdGhlIExQU0sg
bWV0aG9kIG92ZXIgDQogIHRoZSBUTFMgY29ubmVjdGlvbi4gIElmIGF1dGhlbnRpY2F0aW9uIGZh
aWxzLCB0aGUgY29ubmVjdGlvbiBpcyANCiAgdGVybWluYXRlZC4NCjQuSWYgYXV0aGVudGljYXRp
b24gc3VjY2VlZHMsIHRoZSB0d28gZW50aXRpZXMgZXhjaGFuZ2UgU05NUCBtZXNzYWdlcyANCiAg
b3ZlciB0aGUgYXV0aGVudGljYXRlZCBUTFMgY29ubmVjdGlvbi4gIA0KDQpMUFNLIGF1dGhlbnRp
Y2F0aW9uIGlzIGRvbmUgKmFmdGVyKiBUTFMga2V5IGV4Y2hhbmdlIGFuZCBjb25uZWN0aW9uIHNl
dHVwDQp0byBwcmV2ZW50IG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MuDQoNClRoZSBzYW1lIExQ
U0sgYXV0aGVudGljYXRpb24gbWV0aG9kIGNhbiBiZSBydW4gb24gdG9wIG9mIGEgc2Vzc2lvbi1i
YXNlZCwNCmNvbm5lY3Rpb24tbGVzcyB0cmFuc3BvcnQgb3Igb3RoZXIgdHlwZXMgb2YgdHJhbnNw
b3J0LiAgSW4gdGhpcyBjYXNlLCANCmNvbnNpZGVyYXRpb25zIGFsc28gbmVlZCB0byBiZSB0YWtl
biB0byBwcmV2ZW50IG1hbi1pbi10aGUtbWlkZGxlIA0KYXR0YWNrcy4NCiANCkxQU0sgY2FuIGFs
c28gcnVuIG9uIHRvcCBvZiBhbiBpbnNlY3VyZSB0cmFuc3BvcnQgKHBsYWluIFRDUCBvciBVRFAp
LiAgDQpJbiB0aGlzIGNhc2UgaXQgd2lsbCBwcm92aWRlIGFuIJNBdXRoTm9Qcml2lCBsZXZlbCBv
ZiBzZXJ2aWNlLg0KDQoNCjYuIEtleSBNYW5hZ2VtZW50cw0KLS0tLS0tLS0tLS0tLS0tLS0tDQoN
CklmIFRMUyB0cmFuc3BvcnQgaXMgdXNlZCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYW55IGV4dHJh
IGtleSBtYW5hZ2VtZW50IA0Kc2luY2UgdGhlIGtleXMgYXJlIG5lZ290aWF0ZWQgdHJhbnNwYXJl
bnRseSBieSBUTFMga2V5IGV4Y2hhbmdlLg0KDQpJZiBhIGNvbm5lY3Rpb24tbGVzcywgc2Vzc2lv
bi1iYXNlZCAgdHJhbnNwb3J0IGlzIHVzZWQsIHRoZSBMUFNLIHZhbHVlcyANCnBsdXMgc29tZSBy
YW5kb20gdmFsdWVzIGNhbiBiZSB1c2VkIHRvIGdlbmVyYXRlIGVuY3J5cHRpb24gJiBNQUMga2V5
cy4NCg0KDQo3LiBDb25maWd1cmF0aW9ucw0KLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2luY2UgdGhl
IG1vZGVsIHVzZXMgU05NUCB1c2VyIHBhc3N3b3JkIGFuZC9vciBjb21tdW5pdHkgc3RyaW5ncyB0
byANCmdlbmVyYXRlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLCBjb25maWd1cmF0aW9uIGlz
IHNpbXBsaWZpZWQuICBUaGUgDQpMUFNLIHZhbHVlcyBhcmUgY29uZmlndXJlZCBvbiB0aGUgU05N
UCBkZXZpY2UgYXQgdGhlIHNhbWUgdGltZSB0aGUgDQp1c2VycyBhcmUgY29uZmlndXJlZCBvbiB0
aGF0IGRldmljZS4gIEFzIHBhcnQgb2YgYSB1c2VyIGNvbmZpZ3VyYXRpb24sIA0KdGhlIHVzZXIg
cGFzc3dvcmQgaXMgdXNlZCB0byBnZW5lcmF0ZSB0aGUgTFBTSyB2YWx1ZSBhc3NvY2lhdGVkIHdp
dGggDQp0aGF0IHVzZXIuICBUaGUgTFBTSyB2YWx1ZXMsIG5vdCB0aGUgcGFzc3dvcmQsIHdpbGwg
YmUgc3RvcmVkIGluIHRoZSANCmRldmljZS4NCg0KQXMgbWVudGlvbmVkIGVhcmxpZXIsIHRoZSBp
bm5lciBNRDUgaGFzaCBmdW5jdGlvbiBpcyB1c2VkIHRvIHByb3RlY3QgdGhlDQpwYXNzd29yZCBk
dXJpbmcgTFBTSyBjb25maWd1cmF0aW9uLiAgVG8gY29uZmlndXJlIGEgbmV3IHVzZXIgb24gYSBk
ZXZpY2UsDQp0aGUgYWRtaW5pc3RyYXRvci9zdXBlci11c2VyIG9ubHkgbmVlZHMgdG8ga25vdyB0
aGUgaGFzaCB2YWx1ZSBvZiB0aGUgDQpwYXNzd29yZCwgbm90IHRoZSBwbGFpbi10ZXh0IHBhc3N3
b3JkIGl0c2VsZi4gIA0KDQpUbyBtaWdyYXRlIHRvIHRoZSBuZXcgTFBTSyBtb2RlbCBmcm9tIFVT
TSBvciBTTk1QdjEsIGFuIGF1dG9tYXRlZCBzY3JpcHQNCmNhbiBiZSB1c2VkIHRvIGNvbnZlcnQg
dGhlIHBhc3N3b3JkcyBvciBjb21tdW5pdHkgc3RyaW5nIHN0b3JlZCBpbiB0aGUgDQpTTk1QIGRl
dmljZXMgdG8gTFBTSyB2YWx1ZXMuDQoNCkZvciBjZW50cmFsaXplZCBBQUEgc29sdXRpb25zLCB0
aGUgTFBTSyB2YWx1ZXMgKG9yIHRoZSBwYXNzd29yZHMgdG8gDQpnZW5lcmF0ZSB0aGVtKSBjYW4g
YmUgc3RvcmVkIGluIGEgcmVtb3RlIHNlcnZlciBpbnN0ZWFkIG9mIGxvY2FsbHkuICANCkFsbCBv
dGhlciBhc3BlY3RzIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNzIHJlbWFpbiB0aGUgc2Ft
ZS4NCg0KDQo4LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCg0KU2VjdXJlIHRyYW5zcG9ydHMgc3VjaCBhcyBUTFMvU1NIIGFscmVhZHkgcHJvdmlk
ZSBzdHJvbmcgcHJvdGVjdGlvbiBmb3IgDQpkYXRhIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdy
aXR5LiAgQnkgcnVubmluZyBMUFNLIGF1dGhlbnRpY2F0aW9uIG9uIA0KdG9wIG9mIHN1Y2ggc2Vj
dXJlIHRyYW5zcG9ydCwgd2UgY2FuIGhhdmUgYSBjb21wbGV0ZSBzZWN1cml0eSBzb2x1dGlvbiAN
CnRhaWxvcmVkIHRvIHRoZSBuZWVkcyBvZiBTTk1QIGFwcGxpY2F0aW9ucy4NCg0KTGlrZSBvdGhl
ciBwcmUtc2hhcmVkIGtleSBtZXRob2RzLCB0aGVyZSBhcmUgcmlza3MgdGhhdCB0aGUgcHJlLXNo
YXJlZCANCmtleXMgYXJlIGNvbXByb21pc2VkLiAgSW4gTFBTSyBlbnZpcm9ubWVudHMsIHRoZSB2
dWxuZXJhYmlsaXR5IHdpbGwgYmUgDQpsaW1pdGVkOg0KDQorIElmIGEgZGV2aWNlIGlzIGNvbXBy
b21pc2VkLCBpdHMgTFBTSyB2YWx1ZXMgY2FuIG5vdCBiZSB1c2VkIHRvIGFzc3VtZSANCmZhbHNl
IGlkZW50aXR5IG9mIGFub3RoZXIgZGV2aWNlLg0KDQorIElmIGEgZGV2aWNlIGlzIGNvbXByb21p
c2VkLCBpdHMgTFBTSyB2YWx1ZXMgY2FuIG5vdCBiZSB1c2VkIHRvIGxvZ2luIA0KdG8gb3RoZXIg
ZGV2aWNlcw0KDQorIFNOTVAgbWFuYWdlcnMgZG8gbm90IG5lZWQgdG8gc3RvcmUgTFBTSyB2YWx1
ZXMuICBUaGUgTFBTS3MgY2FuIGJlIA0KZ2VuZXJhdGUgb24gdGhlIGZseSB3aGVuIHVzZXJzIGxv
Z2luLg0KDQoNCjkuIFN1bW1hcnkNCi0tLS0tLS0tLS0NClVzaW5nIExQU0sgYXV0aGVudGljYXRp
b24gb24gdG9wIG9mIHRyYW5zcG9ydC1iYXNlZCBzZWN1cml0eSBzZXJ2aWNlcyANCmNhbiBzaW1w
bGlmeSBTTk1QIHNlY3VyaXR5IG1vZGVsIHdoaWxlIGFkZHJlc3NpbmcgbWFueSBsaW1pdGF0aW9u
cyBvZg0KdGhlIGN1cnJlbnQgVVNNIG1vZGVsLiAgVG9nZXRoZXIgd2l0aCBzZWN1cmUgdHJhbnNw
b3J0cyBzdWNoIGFzIFRMUy9TU0gsDQpMUFNLIGF1dGhlbnRpY2F0aW9uIGNhbiBwcm92aWRlcyBh
IGNvbXByZWhlbnNpdmUgYW5kIHN0cm9uZyBzZWN1cml0eSANCnNvbHV0aW9uIHRoYXQgaXMgZWFz
eSB0byBkZXBsb3kgYW5kIG9wZXJhdGUgYW5kIGZsZXhpYmxlIHRvIGFjY29tbW9kYXRlIA0KZnV0
dXJlIGVuY3J5cHRpb24gdGVjaG5vbG9neS4gIA0KDQoNClJlZmVyZW5jZXMNCi0tLS0tLS0tLS0N
Cg0KQW4gQXJjaGl0ZWN0dXJlIGZvciBEZXNjcmliaW5nIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1l
bnQgUHJvdG9jb2wgKFNOTVApDQpNYW5hZ2VtZW50IEZyYW1ld29ya3MsIFJGQyAzNDExLCBEZWNl
bWJlciAyMDAyLg0KDQpVc2VyLWJhc2VkIFNlY3VyaXR5IE1vZGVsIChVU00pIGZvciB2ZXJzaW9u
IDMgb2YgdGhlIFNpbXBsZSBOZXR3b3JrIA0KTWFuYWdlbWVudCBQcm90b2NvbCAoU05NUHYzKSwg
UkZDIDM0MTQsIERlY2VtYmVyIDIwMDIuDQoNClZpZXctYmFzZWQgQWNjZXNzIENvbnRyb2wgTW9k
ZWwgKFZBQ00pIGZvciB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudA0KUHJvdG9jb2wgKFNO
TVApLCBSRkMgMzQxNSwgRGVjZW1iZXIgMjAwMi4NCg0KVHJhbnNwb3J0IE1hcHBpbmcgU2VjdXJp
dHkgTW9kZWwgKFRNU00pIGZvciBTTk1QdjMsIA0KZHJhZnQtc2Nob2Vudy1zbm1wLXRsc20tMDEu
dHh0LCBPY3RvYmVyIDIwMDQNCg0KVGhlIFRMUyBQcm90b2NvbCBWZXJzaW9uIDEuMCwgUkZDIDIy
NDYsIEphbnVhcnkgMTk5OQ0KDQpUaGUgU1JQIEF1dGhlbnRpY2F0aW9uIGFuZCBLZXkgRXhjaGFu
Z2UgU3lzdGVtLCBSRkMgMjk0NSwgU2VwdGVtYmVyIDIwMDANCg0KVXNpbmcgU1JQIGZvciBUTFMg
QXV0aGVudGljYXRpb24sIGRyYWZ0LWlldGYtdGxzLXNycC0wOS50eHQsIA0KTWFyY2ggMTcsIDIw
MDUNCg0KUHJlLVNoYXJlZCBLZXkgQ2lwaGVyc3VpdGVzIGZvciBUTFMsIGRyYWZ0LWlldGYtdGxz
LXBzay0wNy50eHQsIA0KTWFyIDE0LCAyMDA1DQo=

------_=_NextPart_001_01C541E4.185FC77D
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

------_=_NextPart_001_01C541E4.185FC77D--



From isms-bounces@ietf.org  Fri Apr 15 14:17:19 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28254;
	Fri, 15 Apr 2005 14:17:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVXm-0004Zc-RN; Fri, 15 Apr 2005 14:27:55 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMVLl-0003vE-Gt; Fri, 15 Apr 2005 14:15:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVLk-0003v8-CR
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 14:15:28 -0400
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28114
	for <isms@lists.ietf.org>; Fri, 15 Apr 2005 14:15:26 -0400 (EDT)
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-1.cisco.com with ESMTP; 15 Apr 2005 11:13:10 -0700
X-IronPort-AV: i="3.92,105,1112598000"; 
	d="txt'?scan'208"; a="629382552:sNHT2247190910"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3FICW3O003023
	for <isms@lists.ietf.org>; Fri, 15 Apr 2005 11:13:03 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 15 Apr 2005 11:12:27 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C541E6.ADED61A9"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Fri, 15 Apr 2005 11:12:25 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F698@xmb-sjc-22e.amer.cisco.com>
X-MS-Has-Attach: yes
Thread-Index: AcVB5qz0g+WYU9YzS3+gTL/6hk3y8Q==
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 18:12:27.0301 (UTC)
	FILETIME=[AE54E550:01C541E6]
Subject: [Isms] (no subject)
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798

This is a multi-part message in MIME format.

------_=_NextPart_001_01C541E6.ADED61A9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

I am new to this ISMS mailing list and would like to share some thoughts
that I had recently about SNMPv3. Attached please find a proposal to use
localized pre-shared keys for SNMPv3 authentication. This is a
preliminary draft so sorry if some details are missing.=20

The main points of the proposal are:

1. Decouple authentication from data integrity and confidentiality.
2. Data integrity and confidentiality are to be done at the transport
layer (e.g. TLS), similar to the TMSM proposal.
3. Authentication to be done at SNMP application level (on top of a
secure transport).
4. <user ID+password+snmpEngine ID> are used to generate localized
pre-shared keys (LPSK), which are then used to certify the credentials
of the users as well as SNMP devices.
5. A PSK protocol (such as SRP) over a secure transport (e.g. TLS) uses
LPSK-based credentials to authenticate users and devices. No external
auth infrastructure is needed (other than one to configure users and/or
community strings.)

This proposal is an abstract model and does not specify any protocol
selections. I hope that it can be used as a starting point for a new
SNMPv3 authentication model that is secure, simple, and flexible. Your
comments and suggestions will be greatly appreciated.

I'd like to thank Kaushik Narayan and Keith McCloghrie for their early
comments on the proposal. (This is not to say that they endorse it.)

Khanh=20


------_=_NextPart_001_01C541E6.ADED61A9
Content-Type: text/plain;
	name="LPSK.txt"
Content-Description: LPSK.txt
Content-Disposition: attachment;
	filename="LPSK.txt"
Content-Transfer-Encoding: base64

TG9jYWxpemVkIFByZS1TaGFyZWQgS2V5IEF1dGhlbnRpY2F0aW9uIChMUFNLKSBmb3IgU05NUHYz
DQoJCQkJCQkNCktoYW5oIE5ndXllbiAoa2hhbmh2bkBjaXNjby5jb20pDQpBcHIgMTQsIDIwMDUN
Cg0KDQoxLiBJbnRyb2R1Y3Rpb24NCi0tLS0tLS0tLS0tLS0tLQ0KDQpTZWN1cmluZyBhIGNvbW11
bmljYXRpb24gc3lzdGVtIGdlbmVyYWxseSByZXF1aXJlcyB0aHJlZSBtYWluIHNlcnZpY2VzOg0K
LQlBdXRoZW50aWNhdGlvbg0KLQlEYXRhIENvbmZpZGVudGlhbGl0eSAocHJpdmFjeSkNCi0JRGF0
YSBJbnRlZ3JpdHkgKG1lc3NhZ2UgYXV0aGVudGljYXRpb24pDQoNClRoaXMgcHJvcG9zYWwgbGlt
aXRzIGl0cyBzY29wZSB0byB0aGUgYXV0aGVudGljYXRpb24gc2VydmljZSBmb3IgU05NUHYzLg0K
VGhlIG90aGVyIHR3byBzZXJ2aWNlcywgY29uZmlkZW50aWFsaXR5IGFuZCBkYXRhIGludGVncml0
eSwgY2FuIGJlIA0KcHJvdmlkZWQgYnkgYSBzZWN1cmUgdHJhbnNwb3J0IGxheWVyLCBzdWNoIGFz
IFRTTCBvciBTU0gsIGFzIGRlc2NyaWJlZCANCmluIHRoZSBUTVNNIHByb3Bvc2FsLg0KDQpJbiB0
aGlzIHByb3Bvc2FsLCBTTk1QIGVudGl0aWVzIGFyZSBhdXRoZW50aWNhdGVkIHVzaW5nIHRoZSBs
b2NhbGl6ZWQgDQpwcmUtc2hhcmVkIGtleSAoTFBTSykgbWV0aG9kLiAgVGhlIHVzZXIgcGFzc3dv
cmRzIG9yIGNvbW11bml0eSBzdHJpbmdzIA0KYXJlIHVzZWQgdG8gZ2VuZXJhdGUgYXV0aGVudGlj
YXRpb24gY3JlZGVudGlhbHMgZm9yIG5vdCBvbmx5IHVzZXJzIGJ1dCANCmFsc28gU05NUCBlbmdp
bmVzLiAgTm8gZXh0ZXJuYWwgaW5mcmFzdHJ1Y3R1cmUgKGUuZy4gY2VydGlmaWNhdGUgDQptYW5h
Z2VtZW50LCBrZXkgZGlzdHJpYnV0aW9uIHNlcnZlcnMpIGlzIHJlcXVpcmVkLiAgDQoNCg0KMi4g
T2JqZWN0aXZlcw0KLS0tLS0tLS0tLS0tLQ0KDQpUaGUgcHJvcG9zZWQgYXJjaGl0ZWN0dXJlIGFp
bXMgYXQgdGhlIGZvbGxvd2luZyBvYmplY3RpdmVzOg0KDQotIEhpZ2hseSBTZWN1cmUNCi0gU2lt
cGxlIHRvIGltcGxlbWVudA0KLSBFYXN5IHRvIGRlcGxveSBhbmQgb3BlcmF0ZSwgZWFzeSB0byBt
aWdyYXRlIGZyb20gU05NUHYxIGFuZCBVU00NCi0gU3VwcG9ydCBtdWx0aXBsZSB0cmFuc3BvcnQg
c2VjdXJpdHkgb3B0aW9ucw0KLSBTZWxmLWNvbnRhaW5lZCwgZG8gbm90IHJlcXVpcmUgZXh0ZXJu
YWwgaW5mcmFzdHJ1Y3R1cmUgb3RoZXIgdGhhbg0KICBiYXNpYyBuZXR3b3JrIHNlcnZpY2VzDQot
IENvbXBhdGlibGUgd2l0aCBib3RoIHZpZXctYmFzZWQgW1ZBQ01dIGFuZCBjb21tdW5pdHktYmFz
ZWQgYWNjZXNzIA0KICBjb250cm9sIG1vZGVscw0KLSBTdXBwb3J0IENlbnRyYWxpemVkIEFBQQ0K
DQoNCjMuIFNlcGFyYXRpbmcgQXV0aGVudGljYXRpb24gZnJvbSBDb25maWRlbnRpYWxpdHkgYW5k
IERhdGEgSW50ZWdyaXR5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPZiB0aGUgdGhyZWUgYmFzaWMgc2VjdXJp
dHkgc2VydmljZXMsIGF1dGhlbnRpY2F0aW9uIGlzIGFib3V0IHRoZSANCmNvbW11bmljYXRpbmcg
cGFydGllcyAodXNlcnMsIGRldmljZXMsIGV0Yy4pLCB3aGlsZSBjb25maWRlbnRpYWxpdHkgYW5k
IA0KZGF0YSBpbnRlZ3JpdHkgYXJlIGFib3V0IHRoZSBjb21tdW5pY2F0ZWQgZGF0YSAoYml0cyBh
bmQgYnl0ZXMpLiAgIA0KDQpBdXRoZW50aWNhdGlvbiBpcyB2ZXJ5IGFwcGxpY2F0aW9uLXNwZWNp
ZmljLiAgVGhlIG5hdHVyZXMgb2YgdGhlIGVudGl0aWVzDQp0byBiZSBhdXRoZW50aWNhdGVkIHZh
cnkgZnJvbSBvbmUgYXBwbGljYXRpb24gdG8gYW5vdGhlci4gIE9uIHRoZSBvdGhlciANCmhhbmQs
IGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0YSBpbnRlZ3JpdHkgYXJlIG1vcmUgZ2VuZXJpYyBzZXJ2
aWNlcy4gIA0KQXBwbGljYXRpb25zIG9mdGVuIHNoYXJlIHRoZSBzYW1lIGJhc2ljIG5lZWRzIHRo
YXQgdGhlIGJpdHMgYW5kIGJ5dGVzIA0KaW4gdHJhbnNpdCBtdXN0IG5vdCBiZSByZWFkIChjb25m
aWRlbnRpYWxpdHkpIG9yIGFsdGVyZWQgKGludGVncml0eSkgYnkgDQpvdXRzaWRlcnMuICANCg0K
QmVjYXVzZSBvZiB0aGUgYWJvdmUgZGlmZmVyZW5jZSwgaXQgbWF5IGJlIHVzZWZ1bCB0byBkaXZp
ZGUgKGFic3RyYWN0bHkpDQpTTk1QdjMgc2VjdXJpdHkgc3lzdGVtIGludG8gdHdvIHN1Yi1tb2R1
bGVzOiAoMSkgYXV0aGVudGljYXRpb24gYW5kIA0KKDIpIGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0
YSBpbnRlZ3JpdHkuICBJbiB0aGlzIHByb3Bvc2FsLCBhdXRoZW50aWNhdGlvbg0Kd2lsbCBiZSBh
biBpbnRlZ3JhdGVkIHBhcnQgb2YgU05NUCBzZWN1cml0eSBzeXN0ZW0sIHdoaWxlIGNvbmZpZGVu
dGlhbGl0eQ0KYW5kIGRhdGEgaW50ZWdyaXR5IHdpbGwgYmUgaGFuZGxlZCBieSB0aGUgdHJhbnNw
b3J0IGxheWVyLg0KICANCkJ5IG1vZHVsYXJpemluZyB0aGUgU05NUHYzIHNlY3VyaXR5IHN5c3Rl
bSB0aGlzIHdheSwgd2UgY2FuIGhhdmUgdGhlIA0KZmxleGliaWxpdHkgdG8gbWVldCB0aGUgc3Bl
Y2lmaWMgbmVlZHMgb2YgdGhlIFNOTVAgYXBwbGljYXRpb24gd2hpbGUgDQptYXhpbWl6aW5nIHRo
ZSB1c2Ugb2YgY29tbW9uLCBvZmYtdGhlLXNoZWx2ZSBjb21wb25lbnRzIHN1Y2ggYXMgVExTL1NT
SC4NClRoZSBzYW1lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUgdXNlZCB3aXRoIGRpZmZl
cmVudCB0cmFuc3BvcnQgdHlwZXMNCnByb3ZpZGluZyBkaWZmZXJlbnQgbGV2ZWxzIG9mIGRhdGEg
cHJvdGVjdGlvbi4NCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICBTTk1QdjMgU2VjdXJpdHkgU3lz
dGVtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfA0KICAgfCAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgIHwgIHwgICAgICAgICAgICAgICAgTFBTSyBBdXRoZW50
aWNhdGlvbiBTZXJ2aWNlICAgICAgICAgICAgICAgICB8ICB8DQogICB8ICArLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgfA0KICAg
fCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgIHwNCiAgIHwgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0tLS0t
LS0tKyAgKy0tLS0tLS0tLS0tLS0tLS0rICB8DQogICB8ICB8IFNlY3VyZSAgICAgICAgICAgIHwg
IHwgU2VjdXJlICAgICAgICAgIHwgIHwgSW5zZWN1cmUgICAgICAgfCAgfA0KICAgfCAgfCBDb25u
ZWN0bi1vcmllbnRlZCB8ICB8IENvbm5lY3Rpb25sZXNzICB8ICB8IFRyYW5zcG9ydCAgICAgIHwg
IHwNCiAgIHwgIHwgVHJhbnNwb3J0ICAgICAgICAgfCAgfCBUcmFuc3BvcnQgICAgICAgfCAgfCAo
VURQLFRDUCkgICAgICB8ICB8DQogICB8ICB8IChUTFMvU1NIKSAgICAgICAgIHwgIHwgKFNlc3Np
b24tYmFzZWQpIHwgIHwgICAgICAgICAgICAgICAgfCAgfA0KICAgfCAgKy0tLS0tLS0tLS0tLS0t
LS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgIHwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQoNCjQuIExvY2FsaXplZCBQcmUtU2hhcmVkIEtl
eSAoTFBTSykgQXV0aGVudGljYXRpb24gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoaXMgYXJjaGl0ZWN0dXJlIHByb3Bvc2VzIGEgc2VsZi1j
b250YWluZWQgYXV0aGVudGljYXRpb24gZnJhbWV3b3JrIA0KYmFzZWQgb24gdGhlIFBTSyBtZXRo
b2QuIE5vIGV4dGVybmFsIGNyZWRlbnRpYWwgaW5mcmFzdHJ1Y3R1cmUgaXMgbmVlZGVkDQoob3Ro
ZXIgdGhhbiBvbmUgdG8gY29uZmlndXJlIHVzZXJzIGFuZC9vciBjb21tdW5pdHkgc3RyaW5ncy4p
ICBUaGUgdXNlciANCnBhc3N3b3JkcyBhbmQvb3IgY29tbXVuaXR5IHN0cmluZ3MgYXJlIHVzZWQg
dG8gZ2VuZXJhdGUgdGhlIHByZS1zaGFyZWQgDQprZXlzIHRoYXQgYXV0aGVudGljYXRlcyBub3Qg
b25seSB1c2VycyBidXQgYWxzbyBTTk1QIGVuZ2luZXMuDQoNClNlY3VyZSB0cmFuc3BvcnRzIHN1
Y2ggYXMgVExTIG9yIFNTSCBoYXZlIG1hbnkgYnVpbHQtaW4gYXV0aGVudGljYXRpb24gDQptZXRo
b2RzOiBwdWJsaWMta2V5IGNlcnRpZmljYXRlcywgS2VyYmVyb3MsIGhvc3QgZmlsZXMsIGV0Yy4g
IFRoZSBtYWluIA0KZHJhd2JhY2sgb2YgdGhlc2UgbWV0aG9kcyBpcyB0aGF0IHRoZXkgcmVxdWly
ZSBleHRlcm5hbCBpbmZyYXN0cnVjdHVyZSANCihlLmcuIGNlcnRpZmljYXRlIGF1dGhvcml0eSwg
Y2VudHJhbGl6ZWQga2V5IGRpc3RyaWJ1dGlvbiBjZW50ZXIsIGV0Yy4pIA0KdGhhdCBuZWVkIHNp
Z25pZmljYW50IGVmZm9ydHMgdG8gZGVwbG95IGFuZCBvcGVyYXRlLg0KDQpQcmUtc2hhcmVkIGtl
eSBpcyBjb21tb25seSB1c2VkIHRvIHBlcmZvcm0gbXV0dWFsIGF1dGhlbnRpY2F0aW9uLiAgVGhl
IA0KbWFqb3Igd2Vha25lc3Mgb2YgY29udmVudGlvbmFsIFBTSyBhdXRoZW50aWNhdGlvbiBpcyB0
aGF0IHRoZSBzaGFyZWQga2V5DQppcyBrbm93biBieSBtYW55IGVudGl0aWVzLiAgSW4gU05NUCBl
bnZpcm9ubWVudHMsIHdoaWNoIGNhbiBoYXZlIGxhcmdlIA0KbnVtYmVycyBvZiBjb21tdW5pY2F0
aW5nIGVudGl0aWVzLCB0aGlzIGNhbiBiZSBhIHByb2JsZW06IGlmIG9uZSBlbnRpdHkgDQppcyBj
b21wcm9taXNlZCAoZS5nLiBhIGRldmljZSBpcyBzdG9sZW4pLCB0aGUgd2hvbGUgc3lzdGVtIG1h
eSBiZSANCnZ1bG5lcmFibGUuDQoNClRvIGFkZHJlc3MgdGhhdCBpc3N1ZSwgdGhpcyBwcm9wb3Nh
bCB1c2VzIGEgbG9jYWxpemF0aW9uIHNjaGVtZSBzaW1pbGFyIA0KdG8gdGhhdCBvZiB0aGUgVVNN
IG1vZGVsLiAgVGhlIHVzZXIgSUQsIHVzZXIgcGFzc3dvcmQsIGFuZCBTTk1QIEVuZ2luZSBJRA0K
YXJlIGNvbWJpbmVkIHRvIGdlbmVyYXRlIGEgbG9jYWxpemVkIFBTSy4gIFRoZSBMUFNLIHZhbHVl
cywgbm90IHRoZSANCnBhc3N3b3JkcywgYXJlIHN0b3JlZCBpbiB0aGUgZGV2aWNlIGFuZCBzZXJ2
ZSBhcyBib3RoIHRoZSBkZXZpY2UgDQpjcmVkZW50aWFsIChmb3IgZGV2aWNlIGF1dGhlbnRpY2F0
aW9uKSBhcyB3ZWxsIGFzIHRoZSBwYXNzd29yZCANCmF1dGhlbnRpY2F0b3IgKGZvciB1c2VyIGF1
dGhlbnRpY2F0aW9uLikgIFNwZWNpZmljYWxseSwgdGhlIExQU0sgdmFsdWUgDQppcyBnZW5lcmF0
ZWQgYXMgYmVsb3c6DQoNCglMUFNLID0gTUQ1KHVzZXJJRCArIE1ENSh1c2VyIHBhc3N3b3JkKSAr
IHNubXBFbmdpbmVJRCkNCg0KVGhlIHJlYXNvbiB0aGUgaW5uZXIgTUQ1IGlzIHVzZWQgaXMgdG8g
cHJvdGVjdCB0aGUgcGFzc3dvcmQgZHVyaW5nIHVzZXIgDQpjb25maWd1cmF0aW9uLiAgU2VlIHNl
Y3Rpb24gNyAoQ29uZmlndXJhdGlvbnMpIGJlbG93IGZvciBtb3JlIGRldGFpbHMuDQpNRDUgaXMg
dXNlZCBhcyBhbiBleGFtcGxlLiAgQW5vdGhlciBzZWN1cmUgaGFzaCBmdW5jdGlvbiBzdWNoIGFz
IFNIQSBjYW4NCmFsc28gYmUgdXNlZC4NCg0KT25jZSBMUFNLIHZhbHVlcyBhcmUgZGVmaW5lZCwg
dGhleSBjYW4gYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIGEgUFNLIA0KcHJvdG9jb2wgdG8g
bXV0dWFsbHkgYXV0aGVudGljYXRlIHVzZXJzIGFuZCBkZXZpY2VzLiAgVGhlcmUgYXJlIG1hbnkg
UFNLDQphdXRoZW50aWNhdGlvbiBtZXRob2RzLiAgVGhlIFNlY3VyZSBSZW1vdGUgUGFzc3dvcmQg
KFNSUCkgcHJvdG9jb2wgaXMgDQpvbmUgb2YgdGhlbS4gIFNSUCBkb2VzIG5vdCBsb2NhbGl6ZSB0
aGUgc2hhcmVkIGtleSwgc28gdGhlIGxvY2FsaXphdGlvbiANCm1lY2hhbmlzbSBhYm92ZSB3aWxs
IG5lZWQgdG8gYmUgaW1wbGVtZW50ZWQgc2VwYXJhdGVseS4gIFNSUCBpcyBhbiANCmFic3RyYWN0
IHByb3RvY29scyB3aXRoIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucy4gIFRoZXJlIGlzIGFuIElG
VEYgDQpwcm9wb3NhbCB0byBhZGQgU1JQIGF1dGhlbnRpY2F0aW9uIHRvIFRTTCBbVExTIFNSUF0u
ICBCdXQgdG8gYXZvaWQgDQpkZXBlbmRlbmN5IG9uIGEgc3BlY2lmaWMgdHJhbnNwb3J0LCBpdCBt
YXkgYmUgZGVzaXJhYmxlIHRvIHVzZSBhbiANCmFwcGxpY2F0aW9uLWxldmVsIGltcGxlbWVuYXRp
b24gb2YgU1JQLiAgT25lIHN1Y2ggYWx0ZXJuYXRpdmUgaXMgdG8gDQppbXBsZW1lbnQgU1JQIHVz
aW5nIHNubXBHZXQgYW5kL29yIHNubXBTZXQgbWVzc2FnZXMuICBBIHNtYWxsIE1JQiBjYW4gYmUN
CmRlZmluZWQgZm9yIHRoaXMgcHVycG9zZS4NCg0KDQo1LiBJbnRlZ3JhdGlvbiB3aXRoIHRoZSBU
cmFuc3BvcnQgTGF5ZXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQpBcyBtZW50aW9uZWQgZWFybGllciwgdGhpcyBhcmNoaXRlY3R1cmUgcmVsaWVzIG9uIHRoZSB0
cmFuc3BvcnQgbGF5ZXIgDQp0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0YSBpbnRl
Z3JpdHkuICBUaGUgcHJvY2VzcyBvZiANCmF1dGhlbnRpY2F0aW5nIGEgU05NUCBjb21tdW5pY2F0
aW9uIHNlc3Npb24gb3ZlciBhIHNlY3VyZSBjb25uZWN0aW9uLQ0Kb3JpZW50ZWQgdHJhbnNwb3J0
IGlzIGRlc2NyaWJlZCBiZWxvdy4gIFRMUyBpcyB1c2VkIGFzIGFuIGV4YW1wbGUsIA0KYnV0IGFu
b3RoZXIgdHJhbnNwb3J0IHN1Y2ggYXMgU1NIIGNhbiBhbHNvIGJlIHVzZWQuDQoNCjEuVGhlIHR3
byBlbnRpdGllcyAoU05NUCB1c2VyICYgbWFuYWdlZCBkZXZpY2UpIHBlcmZvcm0gVExTIGtleSBl
eGNoYW5nZQ0KICAoRC1IIG9yIFJTQSkgYW5kIG90aGVyIHBhcmFtZXRlciBuZWdvdGlhdGlvbnMu
DQoyLkEgVExTIGNvbm5lY3Rpb24gKHdpdGggbm9BdXRoKSBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVu
IHRoZSB0d28gZW50aXRpZXMuDQogIFRoZSBUTFMgY29ubmVjdGlvbiBpcyBzZWN1cmUgaW4gdGVy
bXMgb2YgY29uZmlkZW50aWFsaXR5IGFuZCBkYXRhIA0KICBpbnRlZ3JpdHkgKGkuZS4gbm8gdGhp
cmQgcGFydHkgY2FuIHJlYWQgb3IgYWx0ZXIgdGhlIGRhdGEgdHJhbnNtaXR0ZWQpLA0KICBidXQg
dGhlIHR3byBlbnRpdGllcyBoYXZlIG5vdCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB5ZXQuDQoz
LlRoZSB0d28gZW50aXRpZXMgYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgdXNpbmcgdGhlIExQU0sg
bWV0aG9kIG92ZXIgDQogIHRoZSBUTFMgY29ubmVjdGlvbi4gIElmIGF1dGhlbnRpY2F0aW9uIGZh
aWxzLCB0aGUgY29ubmVjdGlvbiBpcyANCiAgdGVybWluYXRlZC4NCjQuSWYgYXV0aGVudGljYXRp
b24gc3VjY2VlZHMsIHRoZSB0d28gZW50aXRpZXMgZXhjaGFuZ2UgU05NUCBtZXNzYWdlcyANCiAg
b3ZlciB0aGUgYXV0aGVudGljYXRlZCBUTFMgY29ubmVjdGlvbi4gIA0KDQpMUFNLIGF1dGhlbnRp
Y2F0aW9uIGlzIGRvbmUgKmFmdGVyKiBUTFMga2V5IGV4Y2hhbmdlIGFuZCBjb25uZWN0aW9uIHNl
dHVwDQp0byBwcmV2ZW50IG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MuDQoNClRoZSBzYW1lIExQ
U0sgYXV0aGVudGljYXRpb24gbWV0aG9kIGNhbiBiZSBydW4gb24gdG9wIG9mIGEgc2Vzc2lvbi1i
YXNlZCwNCmNvbm5lY3Rpb24tbGVzcyB0cmFuc3BvcnQgb3Igb3RoZXIgdHlwZXMgb2YgdHJhbnNw
b3J0LiAgSW4gdGhpcyBjYXNlLCANCmNvbnNpZGVyYXRpb25zIGFsc28gbmVlZCB0byBiZSB0YWtl
biB0byBwcmV2ZW50IG1hbi1pbi10aGUtbWlkZGxlIA0KYXR0YWNrcy4NCiANCkxQU0sgY2FuIGFs
c28gcnVuIG9uIHRvcCBvZiBhbiBpbnNlY3VyZSB0cmFuc3BvcnQgKHBsYWluIFRDUCBvciBVRFAp
LiAgDQpJbiB0aGlzIGNhc2UgaXQgd2lsbCBwcm92aWRlIGFuIJNBdXRoTm9Qcml2lCBsZXZlbCBv
ZiBzZXJ2aWNlLg0KDQoNCjYuIEtleSBNYW5hZ2VtZW50cw0KLS0tLS0tLS0tLS0tLS0tLS0tDQoN
CklmIFRMUyB0cmFuc3BvcnQgaXMgdXNlZCwgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYW55IGV4dHJh
IGtleSBtYW5hZ2VtZW50IA0Kc2luY2UgdGhlIGtleXMgYXJlIG5lZ290aWF0ZWQgdHJhbnNwYXJl
bnRseSBieSBUTFMga2V5IGV4Y2hhbmdlLg0KDQpJZiBhIGNvbm5lY3Rpb24tbGVzcywgc2Vzc2lv
bi1iYXNlZCAgdHJhbnNwb3J0IGlzIHVzZWQsIHRoZSBMUFNLIHZhbHVlcyANCnBsdXMgc29tZSBy
YW5kb20gdmFsdWVzIGNhbiBiZSB1c2VkIHRvIGdlbmVyYXRlIGVuY3J5cHRpb24gJiBNQUMga2V5
cy4NCg0KDQo3LiBDb25maWd1cmF0aW9ucw0KLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2luY2UgdGhl
IG1vZGVsIHVzZXMgU05NUCB1c2VyIHBhc3N3b3JkIGFuZC9vciBjb21tdW5pdHkgc3RyaW5ncyB0
byANCmdlbmVyYXRlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLCBjb25maWd1cmF0aW9uIGlz
IHNpbXBsaWZpZWQuICBUaGUgDQpMUFNLIHZhbHVlcyBhcmUgY29uZmlndXJlZCBvbiB0aGUgU05N
UCBkZXZpY2UgYXQgdGhlIHNhbWUgdGltZSB0aGUgDQp1c2VycyBhcmUgY29uZmlndXJlZCBvbiB0
aGF0IGRldmljZS4gIEFzIHBhcnQgb2YgYSB1c2VyIGNvbmZpZ3VyYXRpb24sIA0KdGhlIHVzZXIg
cGFzc3dvcmQgaXMgdXNlZCB0byBnZW5lcmF0ZSB0aGUgTFBTSyB2YWx1ZSBhc3NvY2lhdGVkIHdp
dGggDQp0aGF0IHVzZXIuICBUaGUgTFBTSyB2YWx1ZXMsIG5vdCB0aGUgcGFzc3dvcmQsIHdpbGwg
YmUgc3RvcmVkIGluIHRoZSANCmRldmljZS4NCg0KQXMgbWVudGlvbmVkIGVhcmxpZXIsIHRoZSBp
bm5lciBNRDUgaGFzaCBmdW5jdGlvbiBpcyB1c2VkIHRvIHByb3RlY3QgdGhlDQpwYXNzd29yZCBk
dXJpbmcgTFBTSyBjb25maWd1cmF0aW9uLiAgVG8gY29uZmlndXJlIGEgbmV3IHVzZXIgb24gYSBk
ZXZpY2UsDQp0aGUgYWRtaW5pc3RyYXRvci9zdXBlci11c2VyIG9ubHkgbmVlZHMgdG8ga25vdyB0
aGUgaGFzaCB2YWx1ZSBvZiB0aGUgDQpwYXNzd29yZCwgbm90IHRoZSBwbGFpbi10ZXh0IHBhc3N3
b3JkIGl0c2VsZi4gIA0KDQpUbyBtaWdyYXRlIHRvIHRoZSBuZXcgTFBTSyBtb2RlbCBmcm9tIFVT
TSBvciBTTk1QdjEsIGFuIGF1dG9tYXRlZCBzY3JpcHQNCmNhbiBiZSB1c2VkIHRvIGNvbnZlcnQg
dGhlIHBhc3N3b3JkcyBvciBjb21tdW5pdHkgc3RyaW5nIHN0b3JlZCBpbiB0aGUgDQpTTk1QIGRl
dmljZXMgdG8gTFBTSyB2YWx1ZXMuDQoNCkZvciBjZW50cmFsaXplZCBBQUEgc29sdXRpb25zLCB0
aGUgTFBTSyB2YWx1ZXMgKG9yIHRoZSBwYXNzd29yZHMgdG8gDQpnZW5lcmF0ZSB0aGVtKSBjYW4g
YmUgc3RvcmVkIGluIGEgcmVtb3RlIHNlcnZlciBpbnN0ZWFkIG9mIGxvY2FsbHkuICANCkFsbCBv
dGhlciBhc3BlY3RzIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNzIHJlbWFpbiB0aGUgc2Ft
ZS4NCg0KDQo4LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCg0KU2VjdXJlIHRyYW5zcG9ydHMgc3VjaCBhcyBUTFMvU1NIIGFscmVhZHkgcHJvdmlk
ZSBzdHJvbmcgcHJvdGVjdGlvbiBmb3IgDQpkYXRhIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdy
aXR5LiAgQnkgcnVubmluZyBMUFNLIGF1dGhlbnRpY2F0aW9uIG9uIA0KdG9wIG9mIHN1Y2ggc2Vj
dXJlIHRyYW5zcG9ydCwgd2UgY2FuIGhhdmUgYSBjb21wbGV0ZSBzZWN1cml0eSBzb2x1dGlvbiAN
CnRhaWxvcmVkIHRvIHRoZSBuZWVkcyBvZiBTTk1QIGFwcGxpY2F0aW9ucy4NCg0KTGlrZSBvdGhl
ciBwcmUtc2hhcmVkIGtleSBtZXRob2RzLCB0aGVyZSBhcmUgcmlza3MgdGhhdCB0aGUgcHJlLXNo
YXJlZCANCmtleXMgYXJlIGNvbXByb21pc2VkLiAgSW4gTFBTSyBlbnZpcm9ubWVudHMsIHRoZSB2
dWxuZXJhYmlsaXR5IHdpbGwgYmUgDQpsaW1pdGVkOg0KDQorIElmIGEgZGV2aWNlIGlzIGNvbXBy
b21pc2VkLCBpdHMgTFBTSyB2YWx1ZXMgY2FuIG5vdCBiZSB1c2VkIHRvIGFzc3VtZSANCmZhbHNl
IGlkZW50aXR5IG9mIGFub3RoZXIgZGV2aWNlLg0KDQorIElmIGEgZGV2aWNlIGlzIGNvbXByb21p
c2VkLCBpdHMgTFBTSyB2YWx1ZXMgY2FuIG5vdCBiZSB1c2VkIHRvIGxvZ2luIA0KdG8gb3RoZXIg
ZGV2aWNlcw0KDQorIFNOTVAgbWFuYWdlcnMgZG8gbm90IG5lZWQgdG8gc3RvcmUgTFBTSyB2YWx1
ZXMuICBUaGUgTFBTS3MgY2FuIGJlIA0KZ2VuZXJhdGUgb24gdGhlIGZseSB3aGVuIHVzZXJzIGxv
Z2luLg0KDQoNCjkuIFN1bW1hcnkNCi0tLS0tLS0tLS0NClVzaW5nIExQU0sgYXV0aGVudGljYXRp
b24gb24gdG9wIG9mIHRyYW5zcG9ydC1iYXNlZCBzZWN1cml0eSBzZXJ2aWNlcyANCmNhbiBzaW1w
bGlmeSBTTk1QIHNlY3VyaXR5IG1vZGVsIHdoaWxlIGFkZHJlc3NpbmcgbWFueSBsaW1pdGF0aW9u
cyBvZg0KdGhlIGN1cnJlbnQgVVNNIG1vZGVsLiAgVG9nZXRoZXIgd2l0aCBzZWN1cmUgdHJhbnNw
b3J0cyBzdWNoIGFzIFRMUy9TU0gsDQpMUFNLIGF1dGhlbnRpY2F0aW9uIGNhbiBwcm92aWRlcyBh
IGNvbXByZWhlbnNpdmUgYW5kIHN0cm9uZyBzZWN1cml0eSANCnNvbHV0aW9uIHRoYXQgaXMgZWFz
eSB0byBkZXBsb3kgYW5kIG9wZXJhdGUgYW5kIGZsZXhpYmxlIHRvIGFjY29tbW9kYXRlIA0KZnV0
dXJlIGVuY3J5cHRpb24gdGVjaG5vbG9neS4gIA0KDQoNClJlZmVyZW5jZXMNCi0tLS0tLS0tLS0N
Cg0KQW4gQXJjaGl0ZWN0dXJlIGZvciBEZXNjcmliaW5nIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1l
bnQgUHJvdG9jb2wgKFNOTVApDQpNYW5hZ2VtZW50IEZyYW1ld29ya3MsIFJGQyAzNDExLCBEZWNl
bWJlciAyMDAyLg0KDQpVc2VyLWJhc2VkIFNlY3VyaXR5IE1vZGVsIChVU00pIGZvciB2ZXJzaW9u
IDMgb2YgdGhlIFNpbXBsZSBOZXR3b3JrIA0KTWFuYWdlbWVudCBQcm90b2NvbCAoU05NUHYzKSwg
UkZDIDM0MTQsIERlY2VtYmVyIDIwMDIuDQoNClZpZXctYmFzZWQgQWNjZXNzIENvbnRyb2wgTW9k
ZWwgKFZBQ00pIGZvciB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudA0KUHJvdG9jb2wgKFNO
TVApLCBSRkMgMzQxNSwgRGVjZW1iZXIgMjAwMi4NCg0KVHJhbnNwb3J0IE1hcHBpbmcgU2VjdXJp
dHkgTW9kZWwgKFRNU00pIGZvciBTTk1QdjMsIA0KZHJhZnQtc2Nob2Vudy1zbm1wLXRsc20tMDEu
dHh0LCBPY3RvYmVyIDIwMDQNCg0KVGhlIFRMUyBQcm90b2NvbCBWZXJzaW9uIDEuMCwgUkZDIDIy
NDYsIEphbnVhcnkgMTk5OQ0KDQpUaGUgU1JQIEF1dGhlbnRpY2F0aW9uIGFuZCBLZXkgRXhjaGFu
Z2UgU3lzdGVtLCBSRkMgMjk0NSwgU2VwdGVtYmVyIDIwMDANCg0KVXNpbmcgU1JQIGZvciBUTFMg
QXV0aGVudGljYXRpb24sIGRyYWZ0LWlldGYtdGxzLXNycC0wOS50eHQsIA0KTWFyY2ggMTcsIDIw
MDUNCg0KUHJlLVNoYXJlZCBLZXkgQ2lwaGVyc3VpdGVzIGZvciBUTFMsIGRyYWZ0LWlldGYtdGxz
LXBzay0wNy50eHQsIA0KTWFyIDE0LCAyMDA1DQo=

------_=_NextPart_001_01C541E6.ADED61A9
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

------_=_NextPart_001_01C541E6.ADED61A9--



From isms-bounces@ietf.org  Fri Apr 15 14:18:42 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28439;
	Fri, 15 Apr 2005 14:18:42 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVZ8-0004bm-AZ; Fri, 15 Apr 2005 14:29:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMVMy-00042y-Ax; Fri, 15 Apr 2005 14:16:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVMx-00042h-F4
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 14:16:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28189
	for <isms@ietf.org>; Fri, 15 Apr 2005 14:16:42 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVWz-0004VM-Qb
	for isms@ietf.org; Fri, 15 Apr 2005 14:27:06 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3FIGJA2021945; 
	Fri, 15 Apr 2005 18:16:19 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3FIGBKh012435; 
	Fri, 15 Apr 2005 18:16:18 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041511161604941 ; Fri, 15 Apr 2005 11:16:16 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 11:16:16 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 11:16:15 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 14:16:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 14:15:52 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA987F@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVB3+u2CrqmHzj4TdmfN5MBU348uwABtdMQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "David T. Perkins" <dperkins@dsperkins.com>
X-OriginalArrivalTime: 15 Apr 2005 18:16:14.0403 (UTC)
	FILETIME=[35B1E930:01C541E7]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Content-Transfer-Encoding: quoted-printable

> In URI's message below, he has the the example
> "For USM, it could be dynamically created entry with
> usmUserName=3DsecurityName=3D"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=3Dmsoukup, 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.
> =20
> ________________________________
>=20
> From: Martin Soukup [mailto:msoukup@nortel.com]=20
> Sent: Friday, April 15, 2005 8:53 AM
> To: Blumenthal, Uri; 'isms@ietf.org'
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
>=20
>=20
>=20
> 	Ah - yes. The return of this information (User-Name) in the
> Access-Accept would be supported through configuration of any standard
> RADIUS server.
> 	=20
> 	martin.
>=20
> 		-----Original Message-----
> 		From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20
> 		Sent: Friday, April 15, 2005 10:58 AM
> 		To: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
> 		Subject: RE: [Isms] Discussion: Architecture direction
> for ISMS
> 	=09
> 	=09
> 		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=3DusmSecurityName=3D"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.
>=20
>=20
> ________________________________
>=20
> 			From: isms-bounces@lists.ietf.org
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Martin Soukup
> 			Sent: Friday, April 15, 2005 4:10 AM
> 			To: isms@ietf.org
> 			Subject: RE: [Isms] Discussion: Architecture
> direction for ISMS
> 		=09
> 		=09
>=20
> 			RADIUS "Access-Accept" indicates a successful
> authenthentication response for a user.=20
>=20
> 			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."".
>=20
> 			RADIUS is commonly used to return policy (e.g.
> VACM group mapping) and specific uses have been standardized.=20
>=20
> 			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.
>=20
> 			Uri, I'm not entirely sure what you meant by
> "identity to use" below since authentication presumes an identity was
> already provided?
>=20
> 			Martin.=20
>=20
> 			> -----Original Message-----=20
> 			> From: isms-bounces@lists.ietf.org=20
> 			> [mailto:isms-bounces@lists.ietf.org] On Behalf
> Of Randy Presuhn=20
> 			> Sent: April 14, 2005 8:37 PM=20
> 			> To: isms@ietf.org=20
> 			> Subject: Re: [Isms] Discussion: Architecture
> direction for ISMS=20
> 			>=20
> 			>=20
> 			> Hi -=20
> 			>=20
> 			> > From: "Blumenthal, Uri"
> <uri.blumenthal@intel.com>=20
> 			> > To: "Thierry Moreau"
> <thierry.moreau@connotech.com>=20
> 			> > Cc: <isms@ietf.org>=20
> 			> > Sent: Thursday, April 14, 2005 5:22 PM=20
> 			> > Subject: RE: [Isms] Discussion: Architecture
> direction for ISMS=20
> 			> ...=20
> 			> > So in case of RADIUS, the "access granted"
> should be accompanied by:=20
> 			> >=20
> 			> >  - generated fresh keying for this session
> (including its=20
> 			> life-time);=20
> 			> >  - identity to use for this connection (as
> probably nobody wants to=20
> 			> > configure user database on the SNMP agent
> :-);=20
> 			> >  - mapping of that identity onto an existing
> VACM group.=20
> 			> ...=20
> 			>=20
> 			> Sounds a lot like EUSM.  (not that that'd be a
> bad thing)=20
> 			>=20
> 			> Randy=20
> 			>=20
> 			>=20
> 			>=20
> 			>=20
> 			>
> _______________________________________________=20
> 			> Isms mailing list=20
> 			> Isms@lists.ietf.org=20
> 			> https://www1.ietf.org/mailman/listinfo/isms=20
> 			>=20
> 			>=20
>=20
>=20



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 14:21:41 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28660;
	Fri, 15 Apr 2005 14:21:40 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVc1-0004pe-4a; Fri, 15 Apr 2005 14:32:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMVNL-00045H-JC; Fri, 15 Apr 2005 14:17:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVNK-00045C-QU
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 14:17:06 -0400
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28199
	for <isms@lists.ietf.org>; Fri, 15 Apr 2005 14:17:03 -0400 (EDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 15 Apr 2005 11:16:34 -0700
X-IronPort-AV: i="3.92,105,1112598000"; 
	d="txt'?scan'208"; a="250263181:sNHT56581296"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3FIFliK009680
	for <isms@lists.ietf.org>; Fri, 15 Apr 2005 11:16:27 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 15 Apr 2005 11:16:20 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C541E7.38FA8538"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Fri, 15 Apr 2005 11:16:19 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F69A@xmb-sjc-22e.amer.cisco.com>
X-MS-Has-Attach: yes
Thread-Topic: YAAP (Yet Another Architecture Proposal) - Localized PSK Auth
Thread-Index: AcVB5zh5N0RFO6qzQri14umfyDpjNw==
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 18:16:20.0899 (UTC)
	FILETIME=[39911F30:01C541E7]
Subject: [Isms] YAAP (Yet Another Architecture Proposal) - Localized PSK Auth
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4

This is a multi-part message in MIME format.

------_=_NextPart_001_01C541E7.38FA8538
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sorry, forgot the subject, resend...

---

Hi All,

I am new to this ISMS mailing list and would like to share some thoughts
that I had recently about SNMPv3. Attached please find a proposal to use
localized pre-shared keys for SNMPv3 authentication. This is a
preliminary draft so sorry if some details are missing.=20

The main points of the proposal are:

1. Decouple authentication from data integrity and confidentiality.

2. Data integrity and confidentiality are to be done at the transport
layer (e.g. TLS), similar to the TMSM proposal.

3. Authentication to be done at SNMP application level (on top of a
secure transport).

4. <user ID+password+snmpEngine ID> are used to generate localized
pre-shared keys (LPSK), which are then used to certify the credentials
of the users as well as SNMP devices.

5. A PSK protocol (such as SRP) over a secure transport (e.g. TLS) uses
LPSK-based credentials to authenticate users and devices. No external
auth infrastructure is needed (other than one to configure users and/or
community strings.)

This proposal is an abstract model and does not specify any protocol
selections. I hope that it can be used as a starting point for a new
SNMPv3 authentication model that is secure, simple, and flexible. Your
comments and suggestions will be greatly appreciated.

I'd like to thank Kaushik Narayan and Keith McCloghrie for their early
comments on the proposal. (This is not to say that they endorse it.)

Khanh=20


------_=_NextPart_001_01C541E7.38FA8538
Content-Type: text/plain;
	name="LPSK.txt"
Content-Description: LPSK.txt
Content-Disposition: attachment;
	filename="LPSK.txt"
Content-Transfer-Encoding: base64

TG9jYWxpemVkIFByZS1TaGFyZWQgS2V5IEF1dGhlbnRpY2F0aW9uIChMUFNLKSBmb3IgU05NUHYz
DQoJCQkJCQkNCktoYW5oIE5ndXllbiAoa2hhbmh2bkBjaXNjby5jb20pDQpBcHIgMTQsIDIwMDUN
Cg0KDQoxLiBJbnRyb2R1Y3Rpb24NCi0tLS0tLS0tLS0tLS0tLQ0KDQpTZWN1cmluZyBhIGNvbW11
bmljYXRpb24gc3lzdGVtIGdlbmVyYWxseSByZXF1aXJlcyB0aHJlZSBtYWluIHNlcnZpY2VzOg0K
LQlBdXRoZW50aWNhdGlvbg0KLQlEYXRhIENvbmZpZGVudGlhbGl0eSAocHJpdmFjeSkNCi0JRGF0
YSBJbnRlZ3JpdHkgKG1lc3NhZ2UgYXV0aGVudGljYXRpb24pDQoNClRoaXMgcHJvcG9zYWwgbGlt
aXRzIGl0cyBzY29wZSB0byB0aGUgYXV0aGVudGljYXRpb24gc2VydmljZSBmb3IgU05NUHYzLg0K
VGhlIG90aGVyIHR3byBzZXJ2aWNlcywgY29uZmlkZW50aWFsaXR5IGFuZCBkYXRhIGludGVncml0
eSwgY2FuIGJlIA0KcHJvdmlkZWQgYnkgYSBzZWN1cmUgdHJhbnNwb3J0IGxheWVyLCBzdWNoIGFz
IFRTTCBvciBTU0gsIGFzIGRlc2NyaWJlZCANCmluIHRoZSBUTVNNIHByb3Bvc2FsLg0KDQpJbiB0
aGlzIHByb3Bvc2FsLCBTTk1QIGVudGl0aWVzIGFyZSBhdXRoZW50aWNhdGVkIHVzaW5nIHRoZSBs
b2NhbGl6ZWQgDQpwcmUtc2hhcmVkIGtleSAoTFBTSykgbWV0aG9kLiAgVGhlIHVzZXIgcGFzc3dv
cmRzIG9yIGNvbW11bml0eSBzdHJpbmdzIA0KYXJlIHVzZWQgdG8gZ2VuZXJhdGUgYXV0aGVudGlj
YXRpb24gY3JlZGVudGlhbHMgZm9yIG5vdCBvbmx5IHVzZXJzIGJ1dCANCmFsc28gU05NUCBlbmdp
bmVzLiAgTm8gZXh0ZXJuYWwgaW5mcmFzdHJ1Y3R1cmUgKGUuZy4gY2VydGlmaWNhdGUgDQptYW5h
Z2VtZW50LCBrZXkgZGlzdHJpYnV0aW9uIHNlcnZlcnMpIGlzIHJlcXVpcmVkLiAgDQoNCg0KMi4g
T2JqZWN0aXZlcw0KLS0tLS0tLS0tLS0tLQ0KDQpUaGUgcHJvcG9zZWQgYXJjaGl0ZWN0dXJlIGFp
bXMgYXQgdGhlIGZvbGxvd2luZyBvYmplY3RpdmVzOg0KDQotIEhpZ2hseSBTZWN1cmUNCi0gU2lt
cGxlIHRvIGltcGxlbWVudA0KLSBFYXN5IHRvIGRlcGxveSBhbmQgb3BlcmF0ZSwgZWFzeSB0byBt
aWdyYXRlIGZyb20gU05NUHYxIGFuZCBVU00NCi0gU3VwcG9ydCBtdWx0aXBsZSB0cmFuc3BvcnQg
c2VjdXJpdHkgb3B0aW9ucw0KLSBTZWxmLWNvbnRhaW5lZCwgZG8gbm90IHJlcXVpcmUgZXh0ZXJu
YWwgaW5mcmFzdHJ1Y3R1cmUgb3RoZXIgdGhhbg0KICBiYXNpYyBuZXR3b3JrIHNlcnZpY2VzDQot
IENvbXBhdGlibGUgd2l0aCBib3RoIHZpZXctYmFzZWQgW1ZBQ01dIGFuZCBjb21tdW5pdHktYmFz
ZWQgYWNjZXNzIA0KICBjb250cm9sIG1vZGVscw0KLSBTdXBwb3J0IENlbnRyYWxpemVkIEFBQQ0K
DQoNCjMuIFNlcGFyYXRpbmcgQXV0aGVudGljYXRpb24gZnJvbSBDb25maWRlbnRpYWxpdHkgYW5k
IERhdGEgSW50ZWdyaXR5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPZiB0aGUgdGhyZWUgYmFzaWMgc2VjdXJp
dHkgc2VydmljZXMsIGF1dGhlbnRpY2F0aW9uIGlzIGFib3V0IHRoZSANCmNvbW11bmljYXRpbmcg
cGFydGllcyAodXNlcnMsIGRldmljZXMsIGV0Yy4pLCB3aGlsZSBjb25maWRlbnRpYWxpdHkgYW5k
IA0KZGF0YSBpbnRlZ3JpdHkgYXJlIGFib3V0IHRoZSBjb21tdW5pY2F0ZWQgZGF0YSAoYml0cyBh
bmQgYnl0ZXMpLiAgIA0KDQpBdXRoZW50aWNhdGlvbiBpcyB2ZXJ5IGFwcGxpY2F0aW9uLXNwZWNp
ZmljLiAgVGhlIG5hdHVyZXMgb2YgdGhlIGVudGl0aWVzDQp0byBiZSBhdXRoZW50aWNhdGVkIHZh
cnkgZnJvbSBvbmUgYXBwbGljYXRpb24gdG8gYW5vdGhlci4gIE9uIHRoZSBvdGhlciANCmhhbmQs
IGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0YSBpbnRlZ3JpdHkgYXJlIG1vcmUgZ2VuZXJpYyBzZXJ2
aWNlcy4gIA0KQXBwbGljYXRpb25zIG9mdGVuIHNoYXJlIHRoZSBzYW1lIGJhc2ljIG5lZWRzIHRo
YXQgdGhlIGJpdHMgYW5kIGJ5dGVzIA0KaW4gdHJhbnNpdCBtdXN0IG5vdCBiZSByZWFkIChjb25m
aWRlbnRpYWxpdHkpIG9yIGFsdGVyZWQgKGludGVncml0eSkgYnkgDQpvdXRzaWRlcnMuICANCg0K
QmVjYXVzZSBvZiB0aGUgYWJvdmUgZGlmZmVyZW5jZSwgaXQgbWF5IGJlIHVzZWZ1bCB0byBkaXZp
ZGUgKGFic3RyYWN0bHkpDQpTTk1QdjMgc2VjdXJpdHkgc3lzdGVtIGludG8gdHdvIHN1Yi1tb2R1
bGVzOiAoMSkgYXV0aGVudGljYXRpb24gYW5kIA0KKDIpIGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0
YSBpbnRlZ3JpdHkuICBJbiB0aGlzIHByb3Bvc2FsLCBhdXRoZW50aWNhdGlvbg0Kd2lsbCBiZSBh
biBpbnRlZ3JhdGVkIHBhcnQgb2YgU05NUCBzZWN1cml0eSBzeXN0ZW0sIHdoaWxlIGNvbmZpZGVu
dGlhbGl0eQ0KYW5kIGRhdGEgaW50ZWdyaXR5IHdpbGwgYmUgaGFuZGxlZCBieSB0aGUgdHJhbnNw
b3J0IGxheWVyLg0KICANCkJ5IG1vZHVsYXJpemluZyB0aGUgU05NUHYzIHNlY3VyaXR5IHN5c3Rl
bSB0aGlzIHdheSwgd2UgY2FuIGhhdmUgdGhlIA0KZmxleGliaWxpdHkgdG8gbWVldCB0aGUgc3Bl
Y2lmaWMgbmVlZHMgb2YgdGhlIFNOTVAgYXBwbGljYXRpb24gd2hpbGUgDQptYXhpbWl6aW5nIHRo
ZSB1c2Ugb2YgY29tbW9uLCBvZmYtdGhlLXNoZWx2ZSBjb21wb25lbnRzIHN1Y2ggYXMgVExTL1NT
SC4NClRoZSBzYW1lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUgdXNlZCB3aXRoIGRpZmZl
cmVudCB0cmFuc3BvcnQgdHlwZXMNCnByb3ZpZGluZyBkaWZmZXJlbnQgbGV2ZWxzIG9mIGRhdGEg
cHJvdGVjdGlvbi4NCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICBTTk1QdjMgU2VjdXJpdHkgU3lz
dGVtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfA0KICAgfCAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgIHwgIHwgICAgICAgICAgICAgICAgTFBTSyBBdXRoZW50
aWNhdGlvbiBTZXJ2aWNlICAgICAgICAgICAgICAgICB8ICB8DQogICB8ICArLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgfA0KICAg
fCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgIHwNCiAgIHwgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0tLS0t
LS0tKyAgKy0tLS0tLS0tLS0tLS0tLS0rICB8DQogICB8ICB8IFNlY3VyZSAgICAgICAgICAgIHwg
IHwgU2VjdXJlICAgICAgICAgIHwgIHwgSW5zZWN1cmUgICAgICAgfCAgfA0KICAgfCAgfCBDb25u
ZWN0bi1vcmllbnRlZCB8ICB8IENvbm5lY3Rpb25sZXNzICB8ICB8IFRyYW5zcG9ydCAgICAgIHwg
IHwNCiAgIHwgIHwgVHJhbnNwb3J0ICAgICAgICAgfCAgfCBUcmFuc3BvcnQgICAgICAgfCAgfCAo
VURQLFRDUCkgICAgICB8ICB8DQogICB8ICB8IChUTFMvU1NIKSAgICAgICAgIHwgIHwgKFNlc3Np
b24tYmFzZWQpIHwgIHwgICAgICAgICAgICAgICAgfCAgfA0KICAgfCAgKy0tLS0tLS0tLS0tLS0t
LS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLS0rICArLS0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgIHwg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQoNCjQuIExvY2FsaXplZCBQcmUtU2hhcmVkIEtl
eSAoTFBTSykgQXV0aGVudGljYXRpb24gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoaXMgYXJjaGl0ZWN0dXJlIHByb3Bvc2VzIGEgc2VsZi1j
b250YWluZWQgYXV0aGVudGljYXRpb24gZnJhbWV3b3JrIA0KYmFzZWQgb24gdGhlIFBTSyBtZXRo
b2QuIE5vIGV4dGVybmFsIGNyZWRlbnRpYWwgaW5mcmFzdHJ1Y3R1cmUgaXMgbmVlZGVkDQoob3Ro
ZXIgdGhhbiBvbmUgdG8gY29uZmlndXJlIHVzZXJzIGFuZC9vciBjb21tdW5pdHkgc3RyaW5ncy4p
ICBUaGUgdXNlciANCnBhc3N3b3JkcyBhbmQvb3IgY29tbXVuaXR5IHN0cmluZ3MgYXJlIHVzZWQg
dG8gZ2VuZXJhdGUgdGhlIHByZS1zaGFyZWQgDQprZXlzIHRoYXQgYXV0aGVudGljYXRlcyBub3Qg
b25seSB1c2VycyBidXQgYWxzbyBTTk1QIGVuZ2luZXMuDQoNClNlY3VyZSB0cmFuc3BvcnRzIHN1
Y2ggYXMgVExTIG9yIFNTSCBoYXZlIG1hbnkgYnVpbHQtaW4gYXV0aGVudGljYXRpb24gDQptZXRo
b2RzOiBwdWJsaWMta2V5IGNlcnRpZmljYXRlcywgS2VyYmVyb3MsIGhvc3QgZmlsZXMsIGV0Yy4g
IFRoZSBtYWluIA0KZHJhd2JhY2sgb2YgdGhlc2UgbWV0aG9kcyBpcyB0aGF0IHRoZXkgcmVxdWly
ZSBleHRlcm5hbCBpbmZyYXN0cnVjdHVyZSANCihlLmcuIGNlcnRpZmljYXRlIGF1dGhvcml0eSwg
Y2VudHJhbGl6ZWQga2V5IGRpc3RyaWJ1dGlvbiBjZW50ZXIsIGV0Yy4pIA0KdGhhdCBuZWVkIHNp
Z25pZmljYW50IGVmZm9ydHMgdG8gZGVwbG95IGFuZCBvcGVyYXRlLg0KDQpQcmUtc2hhcmVkIGtl
eSBpcyBjb21tb25seSB1c2VkIHRvIHBlcmZvcm0gbXV0dWFsIGF1dGhlbnRpY2F0aW9uLiAgVGhl
IA0KbWFqb3Igd2Vha25lc3Mgb2YgY29udmVudGlvbmFsIFBTSyBhdXRoZW50aWNhdGlvbiBpcyB0
aGF0IHRoZSBzaGFyZWQga2V5DQppcyBrbm93biBieSBtYW55IGVudGl0aWVzLiAgSW4gU05NUCBl
bnZpcm9ubWVudHMsIHdoaWNoIGNhbiBoYXZlIGxhcmdlIA0KbnVtYmVycyBvZiBjb21tdW5pY2F0
aW5nIGVudGl0aWVzLCB0aGlzIGNhbiBiZSBhIHByb2JsZW06IGlmIG9uZSBlbnRpdHkgDQppcyBj
b21wcm9taXNlZCAoZS5nLiBhIGRldmljZSBpcyBzdG9sZW4pLCB0aGUgd2hvbGUgc3lzdGVtIG1h
eSBiZSANCnZ1bG5lcmFibGUuDQoNClRvIGFkZHJlc3MgdGhhdCBpc3N1ZSwgdGhpcyBwcm9wb3Nh
bCB1c2VzIGEgbG9jYWxpemF0aW9uIHNjaGVtZSBzaW1pbGFyIA0KdG8gdGhhdCBvZiB0aGUgVVNN
IG1vZGVsLiAgVGhlIHVzZXIgSUQsIHVzZXIgcGFzc3dvcmQsIGFuZCBTTk1QIEVuZ2luZSBJRA0K
YXJlIGNvbWJpbmVkIHRvIGdlbmVyYXRlIGEgbG9jYWxpemVkIFBTSy4gIFRoZSBMUFNLIHZhbHVl
cywgbm90IHRoZSANCnBhc3N3b3JkcywgYXJlIHN0b3JlZCBpbiB0aGUgZGV2aWNlIGFuZCBzZXJ2
ZSBhcyBib3RoIHRoZSBkZXZpY2UgDQpjcmVkZW50aWFsIChmb3IgZGV2aWNlIGF1dGhlbnRpY2F0
aW9uKSBhcyB3ZWxsIGFzIHRoZSBwYXNzd29yZCANCmF1dGhlbnRpY2F0b3IgKGZvciB1c2VyIGF1
dGhlbnRpY2F0aW9uLikgIFNwZWNpZmljYWxseSwgdGhlIExQU0sgdmFsdWUgDQppcyBnZW5lcmF0
ZWQgYXMgYmVsb3c6DQoNCglMUFNLID0gTUQ1KHVzZXJJRCArIE1ENSh1c2VyIHBhc3N3b3JkKSAr
IHNubXBFbmdpbmVJRCkNCg0KVGhlIHJlYXNvbiB0aGUgaW5uZXIgTUQ1IGlzIHVzZWQgaXMgdG8g
cHJvdGVjdCB0aGUgcGFzc3dvcmQgZHVyaW5nIHVzZXIgDQpjb25maWd1cmF0aW9uLiAgU2VlIHNl
Y3Rpb24gNyAoQ29uZmlndXJhdGlvbnMpIGJlbG93IGZvciBtb3JlIGRldGFpbHMuDQpNRDUgaXMg
dXNlZCBhcyBhbiBleGFtcGxlLiAgQW5vdGhlciBzZWN1cmUgaGFzaCBmdW5jdGlvbiBzdWNoIGFz
IFNIQSBjYW4NCmFsc28gYmUgdXNlZC4NCg0KT25jZSBMUFNLIHZhbHVlcyBhcmUgZGVmaW5lZCwg
dGhleSBjYW4gYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIGEgUFNLIA0KcHJvdG9jb2wgdG8g
bXV0dWFsbHkgYXV0aGVudGljYXRlIHVzZXJzIGFuZCBkZXZpY2VzLiAgVGhlcmUgYXJlIG1hbnkg
UFNLDQphdXRoZW50aWNhdGlvbiBtZXRob2RzLiAgVGhlIFNlY3VyZSBSZW1vdGUgUGFzc3dvcmQg
KFNSUCkgcHJvdG9jb2wgaXMgDQpvbmUgb2YgdGhlbS4gIFNSUCBkb2VzIG5vdCBsb2NhbGl6ZSB0
aGUgc2hhcmVkIGtleSwgc28gdGhlIGxvY2FsaXphdGlvbiANCm1lY2hhbmlzbSBhYm92ZSB3aWxs
IG5lZWQgdG8gYmUgaW1wbGVtZW50ZWQgc2VwYXJhdGVseS4gIFNSUCBpcyBhbiANCmFic3RyYWN0
IHByb3RvY29scyB3aXRoIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucy4gIFRoZXJlIGlzIGFuIElG
VEYgDQpwcm9wb3NhbCB0byBhZGQgU1JQIGF1dGhlbnRpY2F0aW9uIHRvIFRTTCBbVExTIFNSUF0u
ICBCdXQgdG8gYXZvaWQgDQpkZXBlbmRlbmN5IG9uIGEgc3BlY2lmaWMgdHJhbnNwb3J0LCBpdCBt
YXkgYmUgZGVzaXJhYmxlIHRvIHVzZSBhbiANCmFwcGxpY2F0aW9uLWxldmVsIGltcGxlbWVuYXRp
b24gb2YgU1JQLiAgT25lIHN1Y2ggYWx0ZXJuYXRpdmUgaXMgdG8gDQppbXBsZW1lbnQgU1JQIHVz
aW5nIHNubXBHZXQgYW5kL29yIHNubXBTZXQgbWVzc2FnZXMuICBBIHNtYWxsIE1JQiBjYW4gYmUN
CmRlZmluZWQgZm9yIHRoaXMgcHVycG9zZS4NCg0KDQo1LiBJbnRlZ3JhdGlvbiB3aXRoIHRoZSBU
cmFuc3BvcnQgTGF5ZXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQpBcyBtZW50aW9uZWQgZWFybGllciwgdGhpcyBhcmNoaXRlY3R1cmUgcmVsaWVzIG9uIHRoZSB0
cmFuc3BvcnQgbGF5ZXIgDQp0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBhbmQgZGF0YSBpbnRl
Z3JpdHkuICBUaGUgcHJvY2VzcyBvZiANCmF1dGhlbnRpY2F0aW5nIGEgU05NUCBjb21tdW5pY2F0
aW9uIHNlc3Npb24gb3ZlciBhIHNlY3VyZSBjb25uZWN0aW9uLQ0Kb3JpZW50ZWQgdHJhbnNwb3J0
IGlzIGRlc2NyaWJlZCBiZWxvdy4gIFRMUyBpcyB1c2VkIGFzIGFuIGV4YW1wbGUsIA0KYnV0IGFu
b3RoZXIgdHJhbnNwb3J0IHN1Y2ggYXMgU1NIIGNhbiBhbHNvIGJlIHVzZWQuDQoNCjEuVGhlIHR3
byBlbnRpdGllcyAoU05NUCB1c2VyICYgbWFuYWdlZCBkZXZpY2UpIHBlcmZvcm0gVExTIGtleSBl
eGNoYW5nZQ0KICAoRC1IIG9yIFJTQSkgYW5kIG90aGVyIHBhcmFtZXRlciBuZWdvdGlhdGlvbnMu
DQoyLkEgVExTIGNvbm5lY3Rpb24gKHdpdGggbm9BdXRoKSBpcyBlc3RhYmxpc2hlZCBiZXR3ZWVu
IHRoZSB0d28gZW50aXRpZXMuDQogIFRoZSBUTFMgY29ubmVjdGlvbiBpcyBzZWN1cmUgaW4gdGVy
bXMgb2YgY29uZmlkZW50aWFsaXR5IGFuZCBkYXRhIA0KICBpbnRlZ3JpdHkgKGkuZS4gbm8gdGhp
cmQgcGFydHkgY2FuIHJlYWQgb3IgYWx0ZXIgdGhlIGRhdGEgdHJhbnNtaXR0ZWQpLA0KICBidXQg
dGhlIHR3byBlbnRpdGllcyBoYXZlIG5vdCBhdXRoZW50aWNhdGVkIGVhY2ggb3RoZXIgeWV0Lg0K
My5UaGUgdHdvIGVudGl0aWVzIGF1dGhlbnRpY2F0ZSBlYWNoIG90aGVyIHVzaW5nIHRoZSBMUFNL
IG1ldGhvZCBvdmVyIA0KICB0aGUgVExTIGNvbm5lY3Rpb24uICBJZiBhdXRoZW50aWNhdGlvbiBm
YWlscywgdGhlIGNvbm5lY3Rpb24gaXMgDQogIHRlcm1pbmF0ZWQuDQo0LklmIGF1dGhlbnRpY2F0
aW9uIHN1Y2NlZWRzLCB0aGUgdHdvIGVudGl0aWVzIGV4Y2hhbmdlIFNOTVAgbWVzc2FnZXMgDQog
IG92ZXIgdGhlIGF1dGhlbnRpY2F0ZWQgVExTIGNvbm5lY3Rpb24uICANCg0KTFBTSyBhdXRoZW50
aWNhdGlvbiBpcyBkb25lICphZnRlciogVExTIGtleSBleGNoYW5nZSBhbmQgY29ubmVjdGlvbiBz
ZXR1cA0KdG8gcHJldmVudCBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tzLg0KDQpUaGUgc2FtZSBM
UFNLIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBjYW4gYmUgcnVuIG9uIHRvcCBvZiBhIHNlc3Npb24t
YmFzZWQsDQpjb25uZWN0aW9uLWxlc3MgdHJhbnNwb3J0IG9yIG90aGVyIHR5cGVzIG9mIHRyYW5z
cG9ydC4gIEluIHRoaXMgY2FzZSwgDQpjb25zaWRlcmF0aW9ucyBhbHNvIG5lZWQgdG8gYmUgdGFr
ZW4gdG8gcHJldmVudCBtYW4taW4tdGhlLW1pZGRsZSANCmF0dGFja3MuDQogDQpMUFNLIGNhbiBh
bHNvIHJ1biBvbiB0b3Agb2YgYW4gaW5zZWN1cmUgdHJhbnNwb3J0IChwbGFpbiBUQ1Agb3IgVURQ
KS4gIA0KSW4gdGhpcyBjYXNlIGl0IHdpbGwgcHJvdmlkZSBhbiCTQXV0aE5vUHJpdpQgbGV2ZWwg
b2Ygc2VydmljZS4NCg0KDQo2LiBLZXkgTWFuYWdlbWVudHMNCi0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQpJZiBUTFMgdHJhbnNwb3J0IGlzIHVzZWQsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGFueSBleHRy
YSBrZXkgbWFuYWdlbWVudCANCnNpbmNlIHRoZSBrZXlzIGFyZSBuZWdvdGlhdGVkIHRyYW5zcGFy
ZW50bHkgYnkgVExTIGtleSBleGNoYW5nZS4NCg0KSWYgYSBjb25uZWN0aW9uLWxlc3MsIHNlc3Np
b24tYmFzZWQgIHRyYW5zcG9ydCBpcyB1c2VkLCB0aGUgTFBTSyB2YWx1ZXMgDQpwbHVzIHNvbWUg
cmFuZG9tIHZhbHVlcyBjYW4gYmUgdXNlZCB0byBnZW5lcmF0ZSBlbmNyeXB0aW9uICYgTUFDIGtl
eXMuDQoNCg0KNy4gQ29uZmlndXJhdGlvbnMNCi0tLS0tLS0tLS0tLS0tLS0tDQoNClNpbmNlIHRo
ZSBtb2RlbCB1c2VzIFNOTVAgdXNlciBwYXNzd29yZCBhbmQvb3IgY29tbXVuaXR5IHN0cmluZ3Mg
dG8gDQpnZW5lcmF0ZSBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscywgY29uZmlndXJhdGlvbiBp
cyBzaW1wbGlmaWVkLiAgVGhlIA0KTFBTSyB2YWx1ZXMgYXJlIGNvbmZpZ3VyZWQgb24gdGhlIFNO
TVAgZGV2aWNlIGF0IHRoZSBzYW1lIHRpbWUgdGhlIA0KdXNlcnMgYXJlIGNvbmZpZ3VyZWQgb24g
dGhhdCBkZXZpY2UuICBBcyBwYXJ0IG9mIGEgdXNlciBjb25maWd1cmF0aW9uLCANCnRoZSB1c2Vy
IHBhc3N3b3JkIGlzIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIExQU0sgdmFsdWUgYXNzb2NpYXRlZCB3
aXRoIA0KdGhhdCB1c2VyLiAgVGhlIExQU0sgdmFsdWVzLCBub3QgdGhlIHBhc3N3b3JkLCB3aWxs
IGJlIHN0b3JlZCBpbiB0aGUgDQpkZXZpY2UuDQoNCkFzIG1lbnRpb25lZCBlYXJsaWVyLCB0aGUg
aW5uZXIgTUQ1IGhhc2ggZnVuY3Rpb24gaXMgdXNlZCB0byBwcm90ZWN0IHRoZQ0KcGFzc3dvcmQg
ZHVyaW5nIExQU0sgY29uZmlndXJhdGlvbi4gIFRvIGNvbmZpZ3VyZSBhIG5ldyB1c2VyIG9uIGEg
ZGV2aWNlLA0KdGhlIGFkbWluaXN0cmF0b3Ivc3VwZXItdXNlciBvbmx5IG5lZWRzIHRvIGtub3cg
dGhlIGhhc2ggdmFsdWUgb2YgdGhlIA0KcGFzc3dvcmQsIG5vdCB0aGUgcGxhaW4tdGV4dCBwYXNz
d29yZCBpdHNlbGYuICANCg0KVG8gbWlncmF0ZSB0byB0aGUgbmV3IExQU0sgbW9kZWwgZnJvbSBV
U00gb3IgU05NUHYxLCBhbiBhdXRvbWF0ZWQgc2NyaXB0DQpjYW4gYmUgdXNlZCB0byBjb252ZXJ0
IHRoZSBwYXNzd29yZHMgb3IgY29tbXVuaXR5IHN0cmluZyBzdG9yZWQgaW4gdGhlIA0KU05NUCBk
ZXZpY2VzIHRvIExQU0sgdmFsdWVzLg0KDQpGb3IgY2VudHJhbGl6ZWQgQUFBIHNvbHV0aW9ucywg
dGhlIExQU0sgdmFsdWVzIChvciB0aGUgcGFzc3dvcmRzIHRvIA0KZ2VuZXJhdGUgdGhlbSkgY2Fu
IGJlIHN0b3JlZCBpbiBhIHJlbW90ZSBzZXJ2ZXIgaW5zdGVhZCBvZiBsb2NhbGx5LiAgDQpBbGwg
b3RoZXIgYXNwZWN0cyBvZiB0aGUgYXV0aGVudGljYXRpb24gcHJvY2VzcyByZW1haW4gdGhlIHNh
bWUuDQoNCg0KOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQoNClNlY3VyZSB0cmFuc3BvcnRzIHN1Y2ggYXMgVExTL1NTSCBhbHJlYWR5IHByb3Zp
ZGUgc3Ryb25nIHByb3RlY3Rpb24gZm9yIA0KZGF0YSBjb25maWRlbnRpYWxpdHkgYW5kIGludGVn
cml0eS4gIEJ5IHJ1bm5pbmcgTFBTSyBhdXRoZW50aWNhdGlvbiBvbiANCnRvcCBvZiBzdWNoIHNl
Y3VyZSB0cmFuc3BvcnQsIHdlIGNhbiBoYXZlIGEgY29tcGxldGUgc2VjdXJpdHkgc29sdXRpb24g
DQp0YWlsb3JlZCB0byB0aGUgbmVlZHMgb2YgU05NUCBhcHBsaWNhdGlvbnMuDQoNCkxpa2Ugb3Ro
ZXIgcHJlLXNoYXJlZCBrZXkgbWV0aG9kcywgdGhlcmUgYXJlIHJpc2tzIHRoYXQgdGhlIHByZS1z
aGFyZWQgDQprZXlzIGFyZSBjb21wcm9taXNlZC4gIEluIExQU0sgZW52aXJvbm1lbnRzLCB0aGUg
dnVsbmVyYWJpbGl0eSB3aWxsIGJlIA0KbGltaXRlZDoNCg0KKyBJZiBhIGRldmljZSBpcyBjb21w
cm9taXNlZCwgaXRzIExQU0sgdmFsdWVzIGNhbiBub3QgYmUgdXNlZCB0byBhc3N1bWUgDQpmYWxz
ZSBpZGVudGl0eSBvZiBhbm90aGVyIGRldmljZS4NCg0KKyBJZiBhIGRldmljZSBpcyBjb21wcm9t
aXNlZCwgaXRzIExQU0sgdmFsdWVzIGNhbiBub3QgYmUgdXNlZCB0byBsb2dpbiANCnRvIG90aGVy
IGRldmljZXMNCg0KKyBTTk1QIG1hbmFnZXJzIGRvIG5vdCBuZWVkIHRvIHN0b3JlIExQU0sgdmFs
dWVzLiAgVGhlIExQU0tzIGNhbiBiZSANCmdlbmVyYXRlIG9uIHRoZSBmbHkgd2hlbiB1c2VycyBs
b2dpbi4NCg0KDQo5LiBTdW1tYXJ5DQotLS0tLS0tLS0tDQpVc2luZyBMUFNLIGF1dGhlbnRpY2F0
aW9uIG9uIHRvcCBvZiB0cmFuc3BvcnQtYmFzZWQgc2VjdXJpdHkgc2VydmljZXMgDQpjYW4gc2lt
cGxpZnkgU05NUCBzZWN1cml0eSBtb2RlbCB3aGlsZSBhZGRyZXNzaW5nIG1hbnkgbGltaXRhdGlv
bnMgb2YNCnRoZSBjdXJyZW50IFVTTSBtb2RlbC4gIFRvZ2V0aGVyIHdpdGggc2VjdXJlIHRyYW5z
cG9ydHMgc3VjaCBhcyBUTFMvU1NILA0KTFBTSyBhdXRoZW50aWNhdGlvbiBjYW4gcHJvdmlkZXMg
YSBjb21wcmVoZW5zaXZlIGFuZCBzdHJvbmcgc2VjdXJpdHkgDQpzb2x1dGlvbiB0aGF0IGlzIGVh
c3kgdG8gZGVwbG95IGFuZCBvcGVyYXRlIGFuZCBmbGV4aWJsZSB0byBhY2NvbW1vZGF0ZSANCmZ1
dHVyZSBlbmNyeXB0aW9uIHRlY2hub2xvZ3kuICANCg0KDQpSZWZlcmVuY2VzDQotLS0tLS0tLS0t
DQoNCkFuIEFyY2hpdGVjdHVyZSBmb3IgRGVzY3JpYmluZyBTaW1wbGUgTmV0d29yayBNYW5hZ2Vt
ZW50IFByb3RvY29sIChTTk1QKQ0KTWFuYWdlbWVudCBGcmFtZXdvcmtzLCBSRkMgMzQxMSwgRGVj
ZW1iZXIgMjAwMi4NCg0KVXNlci1iYXNlZCBTZWN1cml0eSBNb2RlbCAoVVNNKSBmb3IgdmVyc2lv
biAzIG9mIHRoZSBTaW1wbGUgTmV0d29yayANCk1hbmFnZW1lbnQgUHJvdG9jb2wgKFNOTVB2Myks
IFJGQyAzNDE0LCBEZWNlbWJlciAyMDAyLg0KDQpWaWV3LWJhc2VkIEFjY2VzcyBDb250cm9sIE1v
ZGVsIChWQUNNKSBmb3IgdGhlIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQNClByb3RvY29sIChT
Tk1QKSwgUkZDIDM0MTUsIERlY2VtYmVyIDIwMDIuDQoNClRyYW5zcG9ydCBNYXBwaW5nIFNlY3Vy
aXR5IE1vZGVsIChUTVNNKSBmb3IgU05NUHYzLCANCmRyYWZ0LXNjaG9lbnctc25tcC10bHNtLTAx
LnR4dCwgT2N0b2JlciAyMDA0DQoNClRoZSBUTFMgUHJvdG9jb2wgVmVyc2lvbiAxLjAsIFJGQyAy
MjQ2LCBKYW51YXJ5IDE5OTkNCg0KVGhlIFNSUCBBdXRoZW50aWNhdGlvbiBhbmQgS2V5IEV4Y2hh
bmdlIFN5c3RlbSwgUkZDIDI5NDUsIFNlcHRlbWJlciAyMDAwDQoNClVzaW5nIFNSUCBmb3IgVExT
IEF1dGhlbnRpY2F0aW9uLCBkcmFmdC1pZXRmLXRscy1zcnAtMDkudHh0LCANCk1hcmNoIDE3LCAy
MDA1DQoNClByZS1TaGFyZWQgS2V5IENpcGhlcnN1aXRlcyBmb3IgVExTLCBkcmFmdC1pZXRmLXRs
cy1wc2stMDcudHh0LCANCk1hciAxNCwgMjAwNQ0K

------_=_NextPart_001_01C541E7.38FA8538
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

------_=_NextPart_001_01C541E7.38FA8538--



From isms-bounces@ietf.org  Fri Apr 15 14:26:48 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28992;
	Fri, 15 Apr 2005 14:26:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVgz-00053z-9r; Fri, 15 Apr 2005 14:37:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMVTj-0004nS-A8; Fri, 15 Apr 2005 14:23:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVTi-0004nJ-F0
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 14:23:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28788
	for <isms@ietf.org>; Fri, 15 Apr 2005 14:23:39 -0400 (EDT)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251]
	helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVdu-0004ye-8f
	for isms@ietf.org; Fri, 15 Apr 2005 14:34:16 -0400
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO005ECF;
	15 Apr 05 14:32:20 -0400
Received: from spooler by Lamicro.com (Mercury/32 v3.32);
	15 Apr 05 14:32:02 -0400
Received: from connotech.com (209.71.204.112) by SMTP.Lamicro.com (Mercury/32
	v3.32) with ESMTP ID MG005ECE; 15 Apr 05 14:31:59 -0400
Message-ID: <42600CEB.8080108@connotech.com>
Date: Fri, 15 Apr 2005 14:50:19 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA9313@pysmsx401.amr.corp.intel.com>	<20050414203701.GB8469@boskop.local>
	<425F0218.4080908@connotech.com> <tslekdcdk4o.fsf@cz.mit.edu>
In-Reply-To: <tslekdcdk4o.fsf@cz.mit.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit



Sam Hartman wrote:
>>>>>>"Thierry" == Thierry Moreau <thierry.moreau@connotech.com> writes:
> 
> 
>     Thierry> Juergen Schoenwaelder wrote:
> 
>     >> 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?
> 
>     Thierry> RADIUS?
> 
>     Thierry> RADIUS with an "implementation-specific" attribute in an
>     Thierry> Access-Request packet to indicate to the RADIUS server
>     Thierry> that some "Authenticate Only" service type request is a
>     Thierry> request to a) authenticate the end- user, b) validate
>     Thierry> that the end-user is allowed SNMPv3 agent registration,
>     Thierry> and c) convey the required keying information to the NAS
>     Thierry> in the network device, in an implementation-specific
>     Thierry> attribute to the RADIUS Access-Accept packet.
> 
> This sounds a lot like inventing Kerberos over RADIUS.  I can't say
> that I'm thrilled with that but I'd need to understand exactly what
> you're proposing better.
> 

In the above message, I was merely SUGGESTING a way out of "So what is 
then left as an option for OOBK?"

Independently (because I did not do the work of reconciling the proposal 
to the OBK architecture), I proposed a scheme using RADIUS, see my 
previous post on "A session-less fix to SNMP security issues?". In 
there, I posted some preliminary ideas for a scheme that (mostly) 
ignored user credentials lifetimes or sessions. You can refer to this 
message for details. If the isms group finds useful bits and pieces from 
there, that's fine.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 14:27:11 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29060;
	Fri, 15 Apr 2005 14:27:11 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVhL-00054P-Sw; Fri, 15 Apr 2005 14:37:48 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMVRQ-0004b5-UO; Fri, 15 Apr 2005 14:21:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVRQ-0004b0-BR
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 14:21:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28588
	for <isms@ietf.org>; Fri, 15 Apr 2005 14:21:19 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVbf-0004oq-HE
	for isms@ietf.org; Fri, 15 Apr 2005 14:31:55 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3FILBA2024083; 
	Fri, 15 Apr 2005 18:21:11 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3FIL5Km015545; 
	Fri, 15 Apr 2005 18:21:10 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041511211005436 ; Fri, 15 Apr 2005 11:21:10 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 11:21:10 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 11:21:10 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 14:21:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 14:20:45 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA988F@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVB3Coay4o4yu9QS/qUHrHBP4EIOAAADTlw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 15 Apr 2005 18:21:08.0311 (UTC)
	FILETIME=[E4E0B670:01C541E7]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: quoted-printable

    Blumenthal> It's the relation between those infrastructures and
    Blumenthal> SNMP identities, and mapping to SNMP Access Control
    Blumenthal> that is missing.

> Yes, I agree that is part of a solution to the charter of this working
> group.  You seem to believe that it will be the hardest part of the
> solution/the part that drives a lot of other decisions.  I'm not sure
> I would go that far.  I do agree it needs to be done and I do agree
> some propoproposals in this WG have not focused on that at all.

Sam, I'm only stating that these things require extra work, both by us -
architecting/designing it, *and* by customers (IT departments) that
deploy it. And it seems that the deployment efforts is exactly what
people are complaining about.=20

> In the ssh case, I'd expect one SNMP engine to have a host key and the
> other to be acting as a user and thus have some username/password,
> public key or something like that.

OK. SNMP engine generates an SSH key for itself (it can be certified
with extra work, or just accepted as today's SSH host keys are). Where
will SNMP engine get the user list? I mean - filling it is likely to be
as easy or difficult, as is filling the USM user table. How will
notifications be protected? By the SSH SNMP engine key itself?

> For Kerberos, I'd expect one SNMP engine to have a long-term service
> key, and the other to have a TGT or something like that.

This seems easy. The only configuration for SNMP engine is its Kerberos
long-term shared-key. No need to fill the user list in advance.

Notifications are somewhat problematic: who to send it to, and under
what protection? Because in Kerberos model, users acquire tickets to
servers but not vs. versa (unless I'm out-of-date on how Kerberos works
- then please explain).

> In the RADIUS case, I'd expect one SNMP engine to have a shared key
> with the RADIUS infrastructure and the other to have a username and
> password.  This case is actually a bit problematic for the
> notification example.

I assume you mean "users have name and password with RADIUS", not with
SNMP engines (so user table doesn't have to be filled). Looks fine.
Notifications do cause some problem, like in Kerberos case.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 14:35:05 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29567;
	Fri, 15 Apr 2005 14:35:05 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMVp0-0005aI-B4; Fri, 15 Apr 2005 14:45:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMVc2-0005jf-Qp; Fri, 15 Apr 2005 14:32:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMVc1-0005jC-Du
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 14:32:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29348
	for <isms@ietf.org>; Fri, 15 Apr 2005 14:32:16 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVmG-0005PX-PH
	for isms@ietf.org; Fri, 15 Apr 2005 14:42:53 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 35BD8E0063; Fri, 15 Apr 2005 14:32:11 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FA988F@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 15 Apr 2005 14:32:11 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA988F@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Fri, 15 Apr 2005 14:20:45 -0400")
Message-ID: <tslfyxrdh78.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

    Blumenthal> It's the relation between those infrastructures and
    Blumenthal> SNMP identities, and mapping to SNMP Access Control
    Blumenthal> that is missing.

    >> Yes, I agree that is part of a solution to the charter of this
    >> working group.  You seem to believe that it will be the hardest
    >> part of the solution/the part that drives a lot of other
    >> decisions.  I'm not sure I would go that far.  I do agree it
    >> needs to be done and I do agree some propoproposals in this WG
    >> have not focused on that at all.

    Blumenthal,> Sam, I'm only stating that these things require extra
    Blumenthal,> work, both by us - architecting/designing it, *and*
    Blumenthal,> by customers (IT departments) that deploy it. And it
    Blumenthal,> seems that the deployment efforts is exactly what
    Blumenthal,> people are complaining about.

Agreed on all counts.

    >> In the ssh case, I'd expect one SNMP engine to have a host key
    >> and the other to be acting as a user and thus have some
    >> username/password, public key or something like that.

    Blumenthal,> OK. SNMP engine generates an SSH key for itself (it
    Blumenthal,> can be certified with extra work, or just accepted as
    Blumenthal,> today's SSH host keys are). Where will SNMP engine
    Blumenthal,> get the user list? I mean - filling it is likely to
    Blumenthal,> be as easy or difficult, as is filling the USM user
    Blumenthal,> table. How will notifications be protected? By the
    Blumenthal,> SSH SNMP engine key itself?

I'd think RADIUS would be a good solution for this particularly because it can convey authorization informatino.

You probably actually want to use the key itself (in ssh publickey
mode) for notifications, but for gets/sets you will often end up using
username/password.  Backing the usernames/passwords with RADIUS seems
reasonable.


    >> For Kerberos, I'd expect one SNMP engine to have a long-term
    >> service key, and the other to have a TGT or something like
    >> that.

    Blumenthal,> This seems easy. The only configuration for SNMP
    Blumenthal,> engine is its Kerberos long-term shared-key. No need
    Blumenthal,> to fill the user list in advance.

    Blumenthal,> Notifications are somewhat problematic: who to send
    Blumenthal,> it to, and under what protection? Because in Kerberos
    Blumenthal,> model, users acquire tickets to servers but not
    Blumenthal,> vs. versa (unless I'm out-of-date on how Kerberos

Ke    Blumenthal,> works - then please explain).

Kerberos has a model called user-to-user where you can get a ticket
for a user.  however I'd expect that most notification deployments
would have some long running service that you send the notifications
to.  I'd expect such a service to be a service in the Kerberos sense
as well and thus be something you could get a ticket for.

    >> In the RADIUS case, I'd expect one SNMP engine to have a shared
    >> key with the RADIUS infrastructure and the other to have a
    >> username and password.  This case is actually a bit problematic
    >> for the notification example.

    Blumenthal,> I assume you mean "users have name and password with
    Blumenthal,> RADIUS", not with SNMP engines (so user table doesn't
    Blumenthal,> have to be filled). Looks fine.  Notifications do
    Blumenthal,> cause some problem, like in Kerberos case.

No.  RADIUS is not a trusted third party protocol; it is a callout
protocol.  It allows one party (the command responder probably) to
avoid having a local username table but instead to use RADIUS.

However whether RADIUS is actually used is a local matter.  We
probably want to specify how to use RADIUS because for our solution to
be easy to deploy people will want something like RADIUS.  however
RADIUS should not show up in the protocol between the two SNMP
engines.  As far as the command generator is concerned, the command
responder may well have a local table.
In practice the responder will use RADIUS for deployment simplicity.




--Sam

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 15:10:09 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04058;
	Fri, 15 Apr 2005 15:10:09 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMWMv-0007nV-PY; Fri, 15 Apr 2005 15:20:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMW69-000253-JH; Fri, 15 Apr 2005 15:03:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMW68-00024y-Hv
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 15:03:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02904
	for <isms@ietf.org>; Fri, 15 Apr 2005 15:03:23 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWGN-0007Pl-GY
	for isms@ietf.org; Fri, 15 Apr 2005 15:14:00 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3FJ3EsC028671; 
	Fri, 15 Apr 2005 12:03:14 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3FJ3D5M025777;
	Fri, 15 Apr 2005 12:03:13 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3FJ3Dm0025773; Fri, 15 Apr 2005 12:03:13 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 15 Apr 2005 12:03:12 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA987F@pysmsx401.amr.corp.intel.com>
Message-ID: <Pine.LNX.4.10.10504151122390.32297-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874

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:msoukup@nortel.com] 
> > Sent: Friday, April 15, 2005 8:53 AM
> > To: Blumenthal, Uri; 'isms@ietf.org'
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> > 
> > 
> > 
> > 	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:uri.blumenthal@intel.com] 
> > 		Sent: Friday, April 15, 2005 10:58 AM
> > 		To: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
> > 		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.
> > 
> > 
> > ________________________________
> > 
> > 			From: isms-bounces@lists.ietf.org
> > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Martin Soukup
> > 			Sent: Friday, April 15, 2005 4:10 AM
> > 			To: isms@ietf.org
> > 			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. 
> > 
> > 			> -----Original Message----- 
> > 			> From: isms-bounces@lists.ietf.org 
> > 			> [mailto:isms-bounces@lists.ietf.org] On Behalf
> > Of Randy Presuhn 
> > 			> Sent: April 14, 2005 8:37 PM 
> > 			> To: isms@ietf.org 
> > 			> Subject: Re: [Isms] Discussion: Architecture
> > direction for ISMS 
> > 			> 
> > 			> 
> > 			> Hi - 
> > 			> 
> > 			> > From: "Blumenthal, Uri"
> > <uri.blumenthal@intel.com> 
> > 			> > To: "Thierry Moreau"
> > <thierry.moreau@connotech.com> 
> > 			> > Cc: <isms@ietf.org> 
> > 			> > Sent: Thursday, April 14, 2005 5:22 PM 
> > 			> > Subject: RE: [Isms] Discussion: Architecture
> > direction for ISMS 
> > 			> ... 
> > 			> > 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. 
> > 			> ... 
> > 			> 
> > 			> Sounds a lot like EUSM.  (not that that'd be a
> > bad thing) 
> > 			> 
> > 			> Randy 
> > 			> 
> > 			> 
> > 			> 
> > 			> 
> > 			>
> > _______________________________________________ 
> > 			> Isms mailing list 
> > 			> Isms@lists.ietf.org 
> > 			> https://www1.ietf.org/mailman/listinfo/isms 
> > 			> 
> > 			> 
> > 
> > 
> 
> 
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 15:26:41 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07330;
	Fri, 15 Apr 2005 15:26:41 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMWcw-0000ji-35; Fri, 15 Apr 2005 15:37:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMWNl-0005yO-8A; Fri, 15 Apr 2005 15:21:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMWNj-0005yJ-Tl
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 15:21:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06664
	for <isms@ietf.org>; Fri, 15 Apr 2005 15:21:34 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWXy-0000R4-E6
	for isms@ietf.org; Fri, 15 Apr 2005 15:32:11 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50) id 1DMWNf-00056r-Vb
	for isms@ietf.org; Fri, 15 Apr 2005 15:21:32 -0400
Date: Fri, 15 Apr 2005 15:22:32 -0400
From: Robert Story <rstory@freesnmp.com>
To: isms@ietf.org
Message-ID: <20050415152232.7b41a689@aud>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Subject: [Isms] updated preference stats
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit

Summarizing again, from recent responses. As before, let me know if I've
mis-characterized your opinion. Summarizing 13 responses (details further
below):

Keying|      For             | Against | Abstain
------+----------------------+---------+-------------
OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment


So it appears that encapsulated keying has the broadest support,
even though 50% of that support is as a second choice. Out of band
keying appears to have the most opponents (though may people just stated a 1st
preference and (mostly) acceptable alternative, and not outright opposition to
the 3rd choice).


Key:  Y=YES/preference    (y=second pref/implied pref)
      M=MAYBE/second pref (m=implied second pref)
      N=NO
      -=no explicit rejection (no comment)

OOB | IB  | EK  | Name (alphabetical by first name)
----+-----+-----+----------------------------------
 N  |  N  |  Y  | David Harrington
 -  |  y  |  -  | David Perkins
 N  |  Y  |  M  | Ira McDonald
 M  |  -  |  Y  | Juergen Schoenwaelder
 Y  |  M  |  -  | Kaushik Narayan
 Y  |  -  |  -  | Marcus Leech
 Y  |  -  |  M  | Martin Soukup
 N  |  Y  |  M  | Robert Story
 m  |  y  |  Y  | Sam Hartman
 Y  |  -  |  m  | Sharon Chisolm
 -  |  M  |  Y  | Tom Petch
 -  |  Y  |  Y  | Uri Blumenthat
 -  |  Y  |  M  | Wes Hardaker

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 15:37:19 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09195;
	Fri, 15 Apr 2005 15:37:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMWnD-0001Wy-HZ; Fri, 15 Apr 2005 15:47:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMWRp-0006cB-7O; Fri, 15 Apr 2005 15:25:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMWRm-0006bq-VB
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 15:25:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07170
	for <isms@ietf.org>; Fri, 15 Apr 2005 15:25:45 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWc1-0000bg-HL
	for isms@ietf.org; Fri, 15 Apr 2005 15:36:22 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3FJNksC008894
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:23:46 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3FJNjf6030278
	for <isms@ietf.org>; Fri, 15 Apr 2005 12:23:45 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3FJNinY030269 for <isms@ietf.org>; Fri, 15 Apr 2005 12:23:45 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 15 Apr 2005 12:23:44 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: isms@ietf.org
Subject: Re: [Isms] RADIUS is not a trusted third party (fwd)
Message-ID: <Pine.LNX.4.10.10504151222500.29869-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44

HI,

This didn't seem to go through....

regards,
/david t. perkins

---------- Forwarded message ----------
Date: Fri, 15 Apr 2005 10:48:09 -0700 (PDT)
From: David T. Perkins <dperkins@dsperkins.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Cc: Martin Soukup <msoukup@nortel.com>, isms@ietf.org
Subject: Re: [Isms] RADIUS is not a trusted third party

HI,

Got to agree with this from Sam, and especially the part
that the "command generator" wil not know which mechanism
(such as Radius) is being used. In the presentation at
the ISMS meeting, this is shown in slide 11
(http://www3.ietf.org/proceedings/05mar/slides/isms-2/sld11.htm)
which shows that when a session is established, the
command responder (called the SNMP agent in the slide),
uses a local policy setting to determine which of potentially
several mechanisms to use for authentication of the
command generator (called the SNMP manager in the slide).


On Fri, 15 Apr 2005, Sam Hartman wrote:

> >>>>> "Martin" == Martin Soukup <msoukup@nortel.com> writes:
> 
>     Martin> RADIUS "Access-Accept" indicates a successful
>     Martin> authenthentication response for a user.
> 
>     Martin> The Access-Accept already returns a "Session-Timeout",
>     Martin> defined as "Sets the maximum number of seconds of service
>     Martin> to be provided to the user before the session
>     Martin> terminates. This attribute value becomes the per-user
>     Martin> "absolute timeout."".
> 
> This only tells the SNMP engine talking to the RADIUS server the
> timeout.  You need to tell the other side of the exchange the timeout
> too.
> 
> Remember that RADIUS is a callout service; it is not a trusted third
> party.  In other words, in a particular SNMP authentication, only one
> of the parties will know that RADIUS is being used.
> 
Regards,
/david t. perkins



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 15:56:43 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14149;
	Fri, 15 Apr 2005 15:56:43 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMX61-00041q-7l; Fri, 15 Apr 2005 16:07:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMWku-0002bT-Op; Fri, 15 Apr 2005 15:45:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMWku-0002bM-70
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 15:45:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10541
	for <isms@ietf.org>; Fri, 15 Apr 2005 15:45:30 -0400 (EDT)
Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWv9-0002Hz-9N
	for isms@ietf.org; Fri, 15 Apr 2005 15:56:08 -0400
Received: from h-64-105-137-140.snvacaid.dynamic.covad.net ([64.105.137.140]
	helo=oemcomputer)
	by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DMWkp-0005tV-00
	for isms@ietf.org; Fri, 15 Apr 2005 12:45:27 -0700
Message-ID: <005c01c541f3$e24d43e0$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <Pine.LNX.4.10.10504150931190.4466-100000@shell4.bayarea.net>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 12:46:57 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <isms@ietf.org>
> Sent: Friday, April 15, 2005 9:35 AM
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
...
> Would you explain your statement "Sounds a lot like EUSM" because
> EUSM didn't invent this, nor is it exclusive to EUSM, nor is
> it key unique characteristic to EUSM that differentiates
> it from other approaches.
...

The EUSM proposal was the only one that *clearly* identified a mechanism
for handling dynamic VACM user->group mappings.  If it was spelled out
in any of the other proposals we looked at, I missed it.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 16:36:35 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22196;
	Fri, 15 Apr 2005 16:36:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMXic-0007fR-0o; Fri, 15 Apr 2005 16:47:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMXS8-0006uD-Hm; Fri, 15 Apr 2005 16:30:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXS7-0006u8-Qi
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 16:30:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21469
	for <isms@ietf.org>; Fri, 15 Apr 2005 16:30:10 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMXcN-0007Bf-4X
	for isms@ietf.org; Fri, 15 Apr 2005 16:40:48 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 4AEED11DA2D; Fri, 15 Apr 2005 13:30:07 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] updated preference stats
Organization: Sparta
References: <20050415152232.7b41a689@aud>
Date: Fri, 15 Apr 2005 13:30:06 -0700
In-Reply-To: <20050415152232.7b41a689@aud> (Robert Story's message of "Fri, 15
	Apr 2005 15:22:32 -0400")
Message-ID: <sdpswvg4vl.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

>>>>> On Fri, 15 Apr 2005 15:22:32 -0400, Robert Story <rstory@freesnmp.com> said:

Robert> Keying|      For             | Against | Abstain
Robert> ------+----------------------+---------+-------------
Robert> OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
Robert> IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
Robert> EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment

I think the consensus is fairly well down to 2 (OOB being
no-conensus).  The other two (IB and EK) are, unfortunately, so of
hard to figure out which is preferred.  Unfortunately, I think either
could be viewed as consensus (IB has more direct support for it, but
some complaints at the same time; EK has no complaints against it
(which, as I said, says a lot) but doesn't have as many first-choices
for.

So the question to the chairs is, do you guys see us being closer to
consensus on some of this issue or not?  If so, does one of the two
resulting ones look closer than the other or should we narrow the
discussion to see what happens from there?  I'm getting worried about
time frames (again) and think we need to move forward.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 16:38:45 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22456;
	Fri, 15 Apr 2005 16:38:45 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMXkh-0007pY-U0; Fri, 15 Apr 2005 16:49:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMXUG-00076w-St; Fri, 15 Apr 2005 16:32:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXUG-00076n-5w
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 16:32:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21642
	for <isms@ietf.org>; Fri, 15 Apr 2005 16:32:22 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMXeV-0007M4-J5
	for isms@ietf.org; Fri, 15 Apr 2005 16:43:00 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 77C9811DA2D; Fri, 15 Apr 2005 13:32:20 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Organization: Sparta
References: <3DEC199BD7489643817ECA151F7C5929FA9439@pysmsx401.amr.corp.intel.com>
Date: Fri, 15 Apr 2005 13:32:19 -0700
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9439@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Thu, 14 Apr 2005 18:55:48 -0400")
Message-ID: <sdd5svg4rw.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a

>>>>> On Thu, 14 Apr 2005 18:55:48 -0400, "Blumenthal, Uri" <uri.blumenthal@intel.com> said:

Wes> EG, if SSH is used then the SSH Host Key will
Wes> likely be a credential for future SNMP engines that are configured to
Wes> allow for an SNMP/SSH transport and at *that* point an engine will
Wes> functionally have a credential.

Uri> I see. Yes it can work. Does it imply that the SSH Host key will
Uri> be shared between SSH daemon and SNMP engine?

I think that's somewhat implementation dependent.  I see advantages of
having the SSH server and a SNMP agent running over SSH sharing the
same key, but I don't see problems with them using different keys as
well and I could see administrators *wanting* separate keys.  From a
protocol point of view, it seems more like a deployment and
implementation problem than something which we should tackle
directly.  If I had to pick one, I'd pick a shared key because it
would be reusing existing infrastructure more and thus I think would
make more operators happy today.  From a security perspective,
however, I don't see the need to rule out the use of separate keys if
someone wanted to configure their systems that way.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 16:40:15 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22548;
	Fri, 15 Apr 2005 16:40:15 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMXm8-0007rM-Ju; Fri, 15 Apr 2005 16:50:53 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMXNp-0006KC-KP; Fri, 15 Apr 2005 16:25:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXNn-0006Jv-K0
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 16:25:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20802
	for <isms@ietf.org>; Fri, 15 Apr 2005 16:25:41 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMXY2-0006ol-Uk
	for isms@ietf.org; Fri, 15 Apr 2005 16:36:20 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 32D5411DA2D; Fri, 15 Apr 2005 13:25:40 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] SSH / Reusability / etc
Organization: Sparta
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
	<tsl64ypdpvh.fsf@cz.mit.edu> <425F7C80.8050007@cisco.com>
	<tslis2of0q0.fsf@cz.mit.edu>
Date: Fri, 15 Apr 2005 13:25:39 -0700
In-Reply-To: <tslis2of0q0.fsf@cz.mit.edu> (Sam Hartman's message of "Fri, 15
	Apr 2005 12:45:11 -0400")
Message-ID: <sd64ynhjng.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64

>>>>> On Fri, 15 Apr 2005 12:45:11 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:

Sam> no.  It is OK to explore use of the ssh keys, although I'm personally
Sam> against it.  As an AD, you'd need to get the secsh wg's cooperation.

Sam> Re use of the ssh protocol is clearly OK if you can make it work.

I think there have been multiple people who have "almost" suggested
using another protocols like TLS and SSH in such a way as to bootstrap
USM with the keys, and then dump the other transport since it was only
used to define keys.  IE, I think there are a number of people that
want to functionally this:

  1) start SSH or TLS between a command generator (CG) and a command
     receiver (CR), for example (obviously not limited to just CG/CR
     pairs).  This would include user authentication in the process
     (anything from Radius, SASL, SSH-keys, ... works here)

  2) once that secure "link" is open, steal its keys (Ks).

  3) close transport

  4) throw Ks into engines for CR/CG

  5) continue with SNMP/USM (over the standard transport port 161 or
     whatever) using Ks and, um, some user name and engineID as yet
     not well discussed.

I *think* people are hinting at this, but no one has stated it clearly
so I can't be sure.

1) I really don't see the benefit in this.  You're starting up
   perfectly secure transport that is actually more secure and
   flexible than USM and then dumping it so you can fall back use
   something that isn't needed.  I don't see how this is simpler than
   merely tunneling SNMP through TLS/SSH or whatever as DTLS wants to
   do.  Heck, you could even do USM processing of the resulting SNMP
   packet that was tunneled if you wanted as long as you ignore the
   results and the security model number was actually different.  I
   won't go farther into this unless someone agrees that what I've
   described is actually what they're wishing to do.

2) this is, in fact, an out of band keying mechanism *not* a
   encapsulated keying mechanism and I hope everyone sees that.  [not
   that it couldn't be a solution, but there is a difference].

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 16:56:36 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24342;
	Fri, 15 Apr 2005 16:56:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMY1y-0000Zs-1i; Fri, 15 Apr 2005 17:07:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMWvS-000704-0R; Fri, 15 Apr 2005 15:56:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMWvQ-0006zg-J0
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 15:56:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13986
	for <isms@ietf.org>; Fri, 15 Apr 2005 15:56:22 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMX5f-0003y8-IW
	for isms@ietf.org; Fri, 15 Apr 2005 16:07:00 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 99F2211DA2D; Fri, 15 Apr 2005 12:56:14 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Robert Story <rstory@freesnmp.com>
Subject: Re: [Isms] updated preference stats
Organization: Sparta
References: <20050415152232.7b41a689@aud>
Date: Fri, 15 Apr 2005 12:56:13 -0700
In-Reply-To: <20050415152232.7b41a689@aud> (Robert Story's message of "Fri, 15
	Apr 2005 15:22:32 -0400")
Message-ID: <sdbr8fizky.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906

>>>>> On Fri, 15 Apr 2005 15:22:32 -0400, Robert Story <rstory@freesnmp.com> said:

Robert> Keying|      For             | Against | Abstain
Robert> ------+----------------------+---------+-------------
...
Robert> EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment


Robert> So it appears that encapsulated keying has the broadest support,
Robert> even though 50% of that support is as a second choice.

It's potentially even more important that no one has voted against
it.  It's often in the IETF the consensus is not what everyone wants,
but the solution that is the one everyone can at least live with.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 17:10:13 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26210;
	Fri, 15 Apr 2005 17:10:13 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYF9-0001Wo-Uo; Fri, 15 Apr 2005 17:20:52 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMXtL-0001xd-T1; Fri, 15 Apr 2005 16:58:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXtK-0001xO-P3
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 16:58:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24531
	for <isms@ietf.org>; Fri, 15 Apr 2005 16:58:16 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMY3a-0000cg-VQ
	for isms@ietf.org; Fri, 15 Apr 2005 17:08:55 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3FKw4A2024388; 
	Fri, 15 Apr 2005 20:58:04 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3FKw1Kf008013; 
	Fri, 15 Apr 2005 20:58:01 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041513580122369 ; Fri, 15 Apr 2005 13:58:01 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 13:57:45 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 13:57:44 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 16:57:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 16:57:20 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9A11@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVB7c921h0wPUCxRwWPVC766NDrpwADq4gA
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "David T. Perkins" <dperkins@dsperkins.com>
X-OriginalArrivalTime: 15 Apr 2005 20:57:43.0297 (UTC)
	FILETIME=[C4B9CF10:01C541FD]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4
Content-Transfer-Encoding: quoted-printable

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:dperkins@dsperkins.com]=20
Sent: Friday, April 15, 2005 12:03 PM
To: Blumenthal, Uri
Cc: Martin Soukup; isms@ietf.org
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.=20

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!=20

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. =20

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=3DsecurityName=3D"msoukup" ..."
> >
> > This would not work!
>=20
> But it will! Se below.
>=20
> > 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.
>=20
> Exactly. And this msgUserName will match either the
dynamically-created
> entry in usmUserTable with usmUserName=3Dmsoukup, or an existing entry
in
> the table becomes operative and authorized for this session (and gets
> keyed).
>=20
> > The value of msgUserName name would be temporal, lasting
> > only the duration of the session, but also unique during
> > its existance.
>=20
> 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.
>=20
> On Fri, 15 Apr 2005, Blumenthal, Uri wrote:
>=20
> > 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.
> > =20
> > ________________________________
> >=20
> > From: Martin Soukup [mailto:msoukup@nortel.com]=20
> > Sent: Friday, April 15, 2005 8:53 AM
> > To: Blumenthal, Uri; 'isms@ietf.org'
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> >=20
> >=20
> >=20
> > 	Ah - yes. The return of this information (User-Name) in the
> > Access-Accept would be supported through configuration of any
standard
> > RADIUS server.
> > 	=20
> > 	martin.
> >=20
> > 		-----Original Message-----
> > 		From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20
> > 		Sent: Friday, April 15, 2005 10:58 AM
> > 		To: Soukup, Martin [CAR:5K50:EXCH]; isms@ietf.org
> > 		Subject: RE: [Isms] Discussion: Architecture direction
> > for ISMS
> > 	=09
> > 	=09
> > 		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=3DusmSecurityName=3D"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.
> >=20
> >=20
> > ________________________________
> >=20
> > 			From: isms-bounces@lists.ietf.org
> > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Martin Soukup
> > 			Sent: Friday, April 15, 2005 4:10 AM
> > 			To: isms@ietf.org
> > 			Subject: RE: [Isms] Discussion: Architecture
> > direction for ISMS
> > 		=09
> > 		=09
> >=20
> > 			RADIUS "Access-Accept" indicates a successful
> > authenthentication response for a user.=20
> >=20
> > 			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."".
> >=20
> > 			RADIUS is commonly used to return policy (e.g.
> > VACM group mapping) and specific uses have been standardized.=20
> >=20
> > 			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.
> >=20
> > 			Uri, I'm not entirely sure what you meant by
> > "identity to use" below since authentication presumes an identity
was
> > already provided?
> >=20
> > 			Martin.=20
> >=20
> > 			> -----Original Message-----=20
> > 			> From: isms-bounces@lists.ietf.org=20
> > 			> [mailto:isms-bounces@lists.ietf.org] On Behalf
> > Of Randy Presuhn=20
> > 			> Sent: April 14, 2005 8:37 PM=20
> > 			> To: isms@ietf.org=20
> > 			> Subject: Re: [Isms] Discussion: Architecture
> > direction for ISMS=20
> > 			>=20
> > 			>=20
> > 			> Hi -=20
> > 			>=20
> > 			> > From: "Blumenthal, Uri"
> > <uri.blumenthal@intel.com>=20
> > 			> > To: "Thierry Moreau"
> > <thierry.moreau@connotech.com>=20
> > 			> > Cc: <isms@ietf.org>=20
> > 			> > Sent: Thursday, April 14, 2005 5:22 PM=20
> > 			> > Subject: RE: [Isms] Discussion: Architecture
> > direction for ISMS=20
> > 			> ...=20
> > 			> > So in case of RADIUS, the "access granted"
> > should be accompanied by:=20
> > 			> >=20
> > 			> >  - generated fresh keying for this session
> > (including its=20
> > 			> life-time);=20
> > 			> >  - identity to use for this connection (as
> > probably nobody wants to=20
> > 			> > configure user database on the SNMP agent
> > :-);=20
> > 			> >  - mapping of that identity onto an existing
> > VACM group.=20
> > 			> ...=20
> > 			>=20
> > 			> Sounds a lot like EUSM.  (not that that'd be a
> > bad thing)=20
> > 			>=20
> > 			> Randy=20
> > 			>=20
> > 			>=20
> > 			>=20
> > 			>=20
> > 			>
> > _______________________________________________=20
> > 			> Isms mailing list=20
> > 			> Isms@lists.ietf.org=20
> > 			> https://www1.ietf.org/mailman/listinfo/isms=20
> > 			>=20
> > 			>=20
> >=20
> >=20
>=20
>=20
>=20


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 17:16:18 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26753;
	Fri, 15 Apr 2005 17:16:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYL3-0001rM-Kx; Fri, 15 Apr 2005 17:26:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMY7k-0004Sa-Ds; Fri, 15 Apr 2005 17:13:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMY7i-0004SS-Po
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 17:13:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26435
	for <isms@ietf.org>; Fri, 15 Apr 2005 17:13:08 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYHz-0001dA-Jk
	for isms@ietf.org; Fri, 15 Apr 2005 17:23:47 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 6A4ED11DA2D; Fri, 15 Apr 2005 14:13:05 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] SSH / Reusability / etc
Organization: Sparta
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
	<tsl64ypdpvh.fsf@cz.mit.edu> <425F7C80.8050007@cisco.com>
	<tslis2of0q0.fsf@cz.mit.edu> <sd64ynhjng.fsf@wes.hardakers.net>
	<tsld5svahvy.fsf@cz.mit.edu>
Date: Fri, 15 Apr 2005 14:13:04 -0700
In-Reply-To: <tsld5svahvy.fsf@cz.mit.edu> (Sam Hartman's message of "Fri, 15
	Apr 2005 16:45:37 -0400")
Message-ID: <sdwtr3eobj.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25

>>>>> On Fri, 15 Apr 2005 16:45:37 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:

Wes> 2) once that secure "link" is open, steal its keys (Ks).

Sam> I'm mostly not OK with this.

We're in agreement then :-)

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 17:18:47 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27007;
	Fri, 15 Apr 2005 17:18:47 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYNR-00021L-Dd; Fri, 15 Apr 2005 17:29:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMXkO-0000l3-6d; Fri, 15 Apr 2005 16:49:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXkI-0000k9-Rv
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 16:49:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23381
	for <isms@ietf.org>; Fri, 15 Apr 2005 16:48:51 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXuS-0008PJ-SE
	for isms@ietf.org; Fri, 15 Apr 2005 16:59:30 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3FKmdsC001915; 
	Fri, 15 Apr 2005 13:48:39 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3FKmcjJ016439;
	Fri, 15 Apr 2005 13:48:38 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3FKmbEf016432; Fri, 15 Apr 2005 13:48:38 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Fri, 15 Apr 2005 13:48:37 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Randy Presuhn <randy_presuhn@mindspring.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
In-Reply-To: <005c01c541f3$e24d43e0$7f1afea9@oemcomputer>
Message-ID: <Pine.LNX.4.10.10504151339130.29869-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

HI,

OK, you are falling into the trap of associating a characteristic
to the first place that you have seen it used.

Well it turns out that the problem of adding a user to the
"to group table" was clearly identified in the BOFs that
predated the EUSM submission. It was not "spelled out"
in the SBSM (and maybe other submissions) because it
was CLEARLY OUTSIDE THE SCOPE of the WG charter.

Let me ask the multipart question again...

What aspect of getting the mapping of identity to group from
a Radius sever:
1) is specific to EUSM
2) works better in EUSM than other approaches
3) a required for EUSM to work (that is, it is a fundamental
   and characteristic part of EUSM)

On Fri, 15 Apr 2005, Randy Presuhn wrote:
> Hi -
> 
> > From: "David T. Perkins" <dperkins@dsperkins.com>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > Cc: <isms@ietf.org>
> > Sent: Friday, April 15, 2005 9:35 AM
> > Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> ...
> > Would you explain your statement "Sounds a lot like EUSM" because
> > EUSM didn't invent this, nor is it exclusive to EUSM, nor is
> > it key unique characteristic to EUSM that differentiates
> > it from other approaches.
> ...
> 
> The EUSM proposal was the only one that *clearly* identified a mechanism
> for handling dynamic VACM user->group mappings.  If it was spelled out
> in any of the other proposals we looked at, I missed it.
> 
> Randy

Regards,
/david t. perkins


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 17:23:56 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27488;
	Fri, 15 Apr 2005 17:23:56 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYSR-0002NB-CD; Fri, 15 Apr 2005 17:34:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMY0s-0003I1-0D; Fri, 15 Apr 2005 17:06:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMY0q-0003Hw-9j
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 17:06:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25599
	for <isms@ietf.org>; Fri, 15 Apr 2005 17:06:02 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYB6-0001Bc-Ol
	for isms@ietf.org; Fri, 15 Apr 2005 17:16:41 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3FL5sA2027922; 
	Fri, 15 Apr 2005 21:05:54 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com
	[132.233.42.129])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3FL5oKf014894; 
	Fri, 15 Apr 2005 21:05:54 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041514055407946 ; Fri, 15 Apr 2005 14:05:54 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 14:05:54 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 14:05:53 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 17:05:52 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Fri, 15 Apr 2005 17:05:30 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9A22@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVB+w960u81TQ1gQgWBDNT53r1D1AAA0OPA
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Wes Hardaker" <hardaker@tislabs.com>,
        "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 15 Apr 2005 21:05:52.0885 (UTC)
	FILETIME=[E88B0250:01C541FE]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: quoted-printable

I don't think this is what people want. IMHO the choices are:

1. Use encapsulation (SNMP messages with different security model) to
obtain keys from RADIUS or Kerberos, use USM with those keys.
2. Use encapsulation (as above) to obtain keys to use some other
security model with them.
3. Somehow invoke TLS or SSH, tunnel SNMP messages through it, somehow
for every packet get the mapping to VACM. Unless "somehow" is replaced
by something tangible and aceptable, I don't like this approach.

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Wes Hardaker
Sent: Friday, April 15, 2005 1:26 PM
To: Sam Hartman
Cc: isms@ietf.org
Subject: Re: [Isms] SSH / Reusability / etc

>>>>> On Fri, 15 Apr 2005 12:45:11 -0400, Sam Hartman
<hartmans-ietf@mit.edu> said:

Sam> no.  It is OK to explore use of the ssh keys, although I'm
personally
Sam> against it.  As an AD, you'd need to get the secsh wg's
cooperation.

Sam> Re use of the ssh protocol is clearly OK if you can make it work.

I think there have been multiple people who have "almost" suggested
using another protocols like TLS and SSH in such a way as to bootstrap
USM with the keys, and then dump the other transport since it was only
used to define keys.  IE, I think there are a number of people that
want to functionally this:

  1) start SSH or TLS between a command generator (CG) and a command
     receiver (CR), for example (obviously not limited to just CG/CR
     pairs).  This would include user authentication in the process
     (anything from Radius, SASL, SSH-keys, ... works here)

  2) once that secure "link" is open, steal its keys (Ks).

  3) close transport

  4) throw Ks into engines for CR/CG

  5) continue with SNMP/USM (over the standard transport port 161 or
     whatever) using Ks and, um, some user name and engineID as yet
     not well discussed.

I *think* people are hinting at this, but no one has stated it clearly
so I can't be sure.

1) I really don't see the benefit in this.  You're starting up
   perfectly secure transport that is actually more secure and
   flexible than USM and then dumping it so you can fall back use
   something that isn't needed.  I don't see how this is simpler than
   merely tunneling SNMP through TLS/SSH or whatever as DTLS wants to
   do.  Heck, you could even do USM processing of the resulting SNMP
   packet that was tunneled if you wanted as long as you ignore the
   results and the security model number was actually different.  I
   won't go farther into this unless someone agrees that what I've
   described is actually what they're wishing to do.

2) this is, in fact, an out of band keying mechanism *not* a
   encapsulated keying mechanism and I hope everyone sees that.  [not
   that it couldn't be a solution, but there is a difference].

--=20
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 17:26:34 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27680;
	Fri, 15 Apr 2005 17:26:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYV0-0002TJ-0Q; Fri, 15 Apr 2005 17:37:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMXhG-0000Ps-Ly; Fri, 15 Apr 2005 16:45:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXhA-0000PP-KG
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 16:45:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23199
	for <isms@ietf.org>; Fri, 15 Apr 2005 16:45:42 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXrQ-0008Bo-8U
	for isms@ietf.org; Fri, 15 Apr 2005 16:56:21 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 4E563E0063; Fri, 15 Apr 2005 16:45:38 -0400 (EDT)
To: Wes Hardaker <hardaker@tislabs.com>
Subject: Re: [Isms] SSH / Reusability / etc
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B22@zcarhxm2.corp.nortel.com>
	<tsl64ypdpvh.fsf@cz.mit.edu> <425F7C80.8050007@cisco.com>
	<tslis2of0q0.fsf@cz.mit.edu> <sd64ynhjng.fsf@wes.hardakers.net>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 15 Apr 2005 16:45:37 -0400
In-Reply-To: <sd64ynhjng.fsf@wes.hardakers.net> (Wes Hardaker's message of
	"Fri, 15 Apr 2005 13:25:39 -0700")
Message-ID: <tsld5svahvy.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17

>>>>> "Wes" == Wes Hardaker <hardaker@tislabs.com> writes:

    Wes> other transport since it was only used to define keys.  IE, I
    Wes> think there are a number of people that want to functionally
    Wes> this:

    Wes>   1) start SSH or TLS between a command generator (CG) and a
    Wes> command receiver (CR), for example (obviously not limited to
    Wes> just CG/CR pairs).  This would include user authentication in
    Wes> the process (anything from Radius, SASL, SSH-keys, ... works
    Wes> here)

I'm OK with this.

    Wes>   2) once that secure "link" is open, steal its keys (Ks).

I'm mostly not OK with this.  For TLS it is acceptable to run
something through the PRF as EAP does and use that as a key.  I don't
think ssh has a similar mechanism.

Using some key intended for one uprpose (such as ssh session
encryption) for another purpose (keying USM) is generally not
acceptable.

One thing you can do once you have a secure transport is send your own
randomly generated (or DHed) keys over that transport.

    Wes>   4) throw Ks into engines for CR/CG

    Wes>   5) continue with SNMP/USM (over the standard transport port
    Wes> 161 or whatever) using Ks and, um, some user name and
    Wes> engineID as yet not well discussed.


Yes, I believe people have been hinting at this.

    Wes> I *think* people are hinting at this, but no one has stated
    Wes> it clearly so I can't be sure.

    Wes> 1) I really don't see the benefit in this.  You're starting
    Wes> up perfectly secure transport that is actually more secure
    Wes> and flexible than USM and then dumping it so you can fall
    Wes> back use something that isn't needed.  I don't see how this
    Wes> is simpler than merely tunneling SNMP through TLS/SSH or
    Wes> whatever as DTLS wants to do.  Heck, you could even do USM
    Wes> processing of the resulting SNMP packet that was tunneled if
    Wes> you wanted as long as you ignore the results and the security
    Wes> model number was actually different.  I won't go farther into
    Wes> this unless someone agrees that what I've described is
    Wes> actually what they're wishing to do.

Personally I agree with you.  I think this is the wrong approach.  I
do not have any blanket objections as an AD to the approach, although
there are a lot of things to get right.  The appropriate use of keys
or confirming that you are within a protocol's applicability statement
are just two examples.

    Wes> 2) this is, in fact, an out of band keying mechanism *not* a
    Wes> encapsulated keying mechanism and I hope everyone sees that.
    Wes> [not that it couldn't be a solution, but there is a
    Wes> difference].

Agreed.  I assume that the people currently proposing OOBK mean
something exactly like what you propose.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 17:52:38 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02654;
	Fri, 15 Apr 2005 17:52:38 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYuE-00046I-2a; Fri, 15 Apr 2005 18:03:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMY1n-0003Sg-6P; Fri, 15 Apr 2005 17:07:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMY1l-0003SJ-02
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 17:07:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25653
	for <isms@ietf.org>; Fri, 15 Apr 2005 17:06:58 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYC1-0001CU-CO
	for isms@ietf.org; Fri, 15 Apr 2005 17:17:37 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3FL6kK5013069; 
	Fri, 15 Apr 2005 21:06:46 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com
	[132.233.42.129])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3FL6hKd015568; 
	Fri, 15 Apr 2005 21:06:43 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041514064308021 ; Fri, 15 Apr 2005 14:06:43 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 14:06:43 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 14:06:43 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 17:06:41 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] updated preference stats
Date: Fri, 15 Apr 2005 17:06:19 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9A24@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] updated preference stats
Thread-Index: AcVB8cM/PfA1+XflQqmyKbITx4C7nQADS4Lg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Robert Story" <rstory@freesnmp.com>, <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 21:06:41.0730 (UTC)
	FILETIME=[05A82A20:01C541FF]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: quoted-printable

Please count me as "reject OOB". Tnx!=20

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Robert Story
Sent: Friday, April 15, 2005 12:23 PM
To: isms@ietf.org
Subject: [Isms] updated preference stats

Summarizing again, from recent responses. As before, let me know if I've
mis-characterized your opinion. Summarizing 13 responses (details
further
below):

Keying|      For             | Against | Abstain
------+----------------------+---------+-------------
OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment


So it appears that encapsulated keying has the broadest support,
even though 50% of that support is as a second choice. Out of band
keying appears to have the most opponents (though may people just stated
a 1st
preference and (mostly) acceptable alternative, and not outright
opposition to
the 3rd choice).


Key:  Y=3DYES/preference    (y=3Dsecond pref/implied pref)
      M=3DMAYBE/second pref (m=3Dimplied second pref)
      N=3DNO
      -=3Dno explicit rejection (no comment)

OOB | IB  | EK  | Name (alphabetical by first name)
----+-----+-----+----------------------------------
 N  |  N  |  Y  | David Harrington
 -  |  y  |  -  | David Perkins
 N  |  Y  |  M  | Ira McDonald
 M  |  -  |  Y  | Juergen Schoenwaelder
 Y  |  M  |  -  | Kaushik Narayan
 Y  |  -  |  -  | Marcus Leech
 Y  |  -  |  M  | Martin Soukup
 N  |  Y  |  M  | Robert Story
 m  |  y  |  Y  | Sam Hartman
 Y  |  -  |  m  | Sharon Chisolm
 -  |  M  |  Y  | Tom Petch
 -  |  Y  |  Y  | Uri Blumenthat
 -  |  Y  |  M  | Wes Hardaker

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 18:04:50 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03517;
	Fri, 15 Apr 2005 18:04:50 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMZ61-0004ih-Cz; Fri, 15 Apr 2005 18:15:30 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMYCj-00053e-Pf; Fri, 15 Apr 2005 17:18:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMYCh-00053O-RY
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 17:18:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26945
	for <isms@ietf.org>; Fri, 15 Apr 2005 17:18:17 -0400 (EDT)
Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYMy-00020R-Nx
	for isms@ietf.org; Fri, 15 Apr 2005 17:28:57 -0400
Received: from h-64-105-137-140.snvacaid.dynamic.covad.net ([64.105.137.140]
	helo=oemcomputer)
	by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DMYCg-0004Io-00
	for isms@ietf.org; Fri, 15 Apr 2005 14:18:18 -0700
Message-ID: <020d01c54200$dc4e9d60$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <Pine.LNX.4.10.10504151339130.29869-100000@shell4.bayarea.net>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Fri, 15 Apr 2005 14:19:50 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 2.9 (++)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4

Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <isms@ietf.org>
> Sent: Friday, April 15, 2005 1:48 PM
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
>

> HI,
>
> OK, you are falling into the trap of associating a characteristic
> to the first place that you have seen it used.
>
> Well it turns out that the problem of adding a user to the
> "to group table" was clearly identified in the BOFs that
> predated the EUSM submission. It was not "spelled out"
> in the SBSM (and maybe other submissions) because it
> was CLEARLY OUTSIDE THE SCOPE of the WG charter.

Dave, there's no need to get all bent out of shape.  All I said
was "Sounds a lot like EUSM".  If you felt that this was somehow
disparaging of other proposals, you're reading far too much into
the comment, and wasting energy that would be better spent
on technical discussion.

> Let me ask the multipart question again...
>
> What aspect of getting the mapping of identity to group from
> a Radius sever:
> 1) is specific to EUSM

I've made no such claim, although it was the only proposal
that spelled it out.  As we wrote in the evaluation, we *liked*
this aspect, because even though it goes farther than the
letter of the charter, it is clearly needed for a solution that
minimizes the need to touch managed devices every time
a new user is added.

> 2) works better in EUSM than other approaches

I've made no such claim, and I don't see why there's any
value to arguing this point one way or the other.

> 3) a required for EUSM to work (that is, it is a fundamental
>    and characteristic part of EUSM)

Without it, an important benefit of EUSM would go away:
the ability to support the addition of users to the user/identity
management system without needing to touch managed devices.

But the real issue, from my perspective, is that *whatever* approach
this WG goes with needs to address the VACM user->group
mapping.  Failure to do so will, in my opinion, produce a solution
that is administratively no more appealing than what we have today,
since it would *still* require the administrator to go out and touch
every managed device that a user might access.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 18:06:18 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03698;
	Fri, 15 Apr 2005 18:06:18 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMZ7S-0004qe-40; Fri, 15 Apr 2005 18:16:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMYbi-0007os-BS; Fri, 15 Apr 2005 17:44:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMYbg-0007oh-Oo
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 17:44:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01482
	for <isms@ietf.org>; Fri, 15 Apr 2005 17:44:06 -0400 (EDT)
Received: from ib0bf.i.pppool.de ([85.73.176.191] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYlv-0003X5-5o
	for isms@ietf.org; Fri, 15 Apr 2005 17:54:44 -0400
Received: by boskop.local (Postfix, from userid 501)
	id 41C0B27E35E; Fri, 15 Apr 2005 23:43:46 +0200 (CEST)
Date: Fri, 15 Apr 2005 23:43:46 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] SSH / Reusability / etc
Message-ID: <20050415214346.GA879@boskop.local>
Mail-Followup-To: "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	Wes Hardaker <hardaker@tislabs.com>,
	Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
References: <3DEC199BD7489643817ECA151F7C5929FA9A22@pysmsx401.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9A22@pysmsx401.amr.corp.intel.com>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a

On Fri, Apr 15, 2005 at 05:05:30PM -0400, Blumenthal, Uri wrote:

> 3. Somehow invoke TLS or SSH, tunnel SNMP messages through it, somehow
> for every packet get the mapping to VACM. Unless "somehow" is replaced
> by something tangible and aceptable, I don't like this approach.

All you need to do is an authentication exchange once the secure 
transport is open which gives you a securityName.

I fail to see why SNMP is fundamentally different from other protocols
where you establish a secure tunnel, some sort of authentication exchange 
over the secure tunnel and then finally access control decisions based 
on the authenticated identity.  The only reason this may look ugly is 
the way the SNMP architecture forces the complete security subsystem 
into the middle of the SNMP blob, to be called in the middle of the 
message processing.

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 18:10:10 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04289;
	Fri, 15 Apr 2005 18:10:10 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMZBB-0004wz-9D; Fri, 15 Apr 2005 18:20:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMYhR-0000An-6D; Fri, 15 Apr 2005 17:50:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMYhP-0000AO-EY
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 17:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02445
	for <isms@ietf.org>; Fri, 15 Apr 2005 17:50:01 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMYrf-0003uu-D0
	for isms@ietf.org; Fri, 15 Apr 2005 18:00:40 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 15 Apr 2005 14:48:44 -0700
X-IronPort-AV: i="3.92,106,1112598000"; 
	d="scan'208"; a="250349941:sNHT1031097472"
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com
	[171.71.163.34])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3FLmeKx022159
	for <isms@ietf.org>; Fri, 15 Apr 2005 14:48:40 -0700 (PDT)
Received: from kaushik-w2k03.cisco.com (dhcp-171-71-192-248.cisco.com
	[171.71.192.248]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR)
	with ESMTP id BAA53724; Fri, 15 Apr 2005 14:48:41 -0700 (PDT)
Message-Id: <6.2.0.14.0.20050415144424.049690b0@mira-sjc5-a.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 15 Apr 2005 14:48:41 -0700
To: isms@ietf.org
From: Kaushik Narayan <kaushik@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: [Isms] USM Protection vs Transport Protection
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25

Hi All,

Having gone through the discussion of architectural
choices, I think the first decision that we might want
to make is whether we need continue to use USM for
message protection vs. using some other protection
mechanism such as the transport protection suggested
by TLSM.

regards,
   kaushik!

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 19:25:15 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09257;
	Fri, 15 Apr 2005 19:25:15 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMaLq-0000Mn-Ez; Fri, 15 Apr 2005 19:35:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMZSg-0004rT-N0; Fri, 15 Apr 2005 18:38:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZSf-0004rJ-UG
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 18:38:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06700
	for <isms@ietf.org>; Fri, 15 Apr 2005 18:38:51 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZcw-0006W9-Fc
	for isms@ietf.org; Fri, 15 Apr 2005 18:49:31 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-5.cisco.com with ESMTP; 15 Apr 2005 15:38:43 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3FMc5pv013375
	for <isms@ietf.org>; Fri, 15 Apr 2005 15:38:41 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 15 Apr 2005 15:38:36 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] USM Protection vs Transport Protection
Date: Fri, 15 Apr 2005 15:38:36 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F6D9@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] USM Protection vs Transport Protection
Thread-Index: AcVCB/Y1Epa6qN5yT7agVdelVD8mMAAAeY2w
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Kaushik Narayan \(kaushik\)" <kaushik@cisco.com>, <isms@ietf.org>
X-OriginalArrivalTime: 15 Apr 2005 22:38:36.0698 (UTC)
	FILETIME=[DCD57FA0:01C5420B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: quoted-printable

Good point. =20

My opinion is that we should rely on transport protection as much as
possible (key exchange, encryption, MAC...), except authentication (I
mean user/device auth, not MAC), which is better to be handled at SNMP
application level.

This is similar to HTTPS, which runs HTTP over SSL/TLS.  In HTTPS
environments, user authentication is often done by HTML/HTTP
applications, 'over', not 'by' SSL/TLS transport.  For SNMP, we can use
a similar way not only for user but also device auth.

Khanh

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Kaushik Narayan (kaushik)
Sent: Friday, April 15, 2005 2:49 PM
To: isms@ietf.org
Subject: [Isms] USM Protection vs Transport Protection

Hi All,

Having gone through the discussion of architectural choices, I think the
first decision that we might want to make is whether we need continue to
use USM for message protection vs. using some other protection mechanism
such as the transport protection suggested by TLSM.

regards,
   kaushik!

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 20:14:14 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11798;
	Fri, 15 Apr 2005 20:14:14 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMb7G-0002u1-Aq; Fri, 15 Apr 2005 20:24:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMauq-0003tg-IB; Fri, 15 Apr 2005 20:12:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMauo-0003tQ-MJ
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 20:12:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11753
	for <isms@ietf.org>; Fri, 15 Apr 2005 20:12:01 -0400 (EDT)
Message-Id: <200504160012.UAA11753@ietf.org>
Received: from rwcrmhc14.comcast.net ([216.148.227.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMb56-0002m4-V4
	for isms@ietf.org; Fri, 15 Apr 2005 20:22:41 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc14) with SMTP
	id <20050416001152014005l70ve>; Sat, 16 Apr 2005 00:11:52 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Wes Hardaker'" <hardaker@tislabs.com>,
        "'Sam Hartman'" <hartmans-ietf@mit.edu>
Subject: RE: [Isms] SSH / Reusability / etc
Date: Fri, 15 Apr 2005 20:11:46 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <sd64ynhjng.fsf@wes.hardakers.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVB+1R8mal7usJYQqWwjTMfK9q1EQAGnVQA
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit

Hi,

So there is no ambiguity, 

1) I do not support copying the keys from another protocol to stuff
into USM. I think that approach creates the potential for exposure of
the keys, which would weaken both protocols.

2) I can live with having the SNMP keys delivered to an SNMP security
model over a secure protocol, but that would not be my preference
because I think it creates the potential for exposure of the keys.
This could be slightly problematic remaining in sync with a
centralized server ( a fired operator whose credentials are removed
from RADIUS, might still have access to SNMP devices until the keys
were removed from the SNMP entity.)

3) My preference is to have SNMP be ignorant of the authentication
credentials used by another protocol, and to have that protocol simply
inform the SNMP security model of the authenticated user identity. The
security model might then dynamically stuff the securityname and other
necessary parameters into the USM MIB or a similar MIB so the SNMP
engine components can utilize the securityName to provide access
control, audit logging, etc. based on the securityName.

4) I would like to see the authentication server also provide
authorization information that ties into the VACM groupname table or a
similar approach to identifying which acceess control "policy" should
be applied for this security principal. I support the use of RADIUS or
other AAA server as one source for authorization policy.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker
> Sent: Friday, April 15, 2005 4:26 PM
> To: Sam Hartman
> Cc: isms@ietf.org
> Subject: Re: [Isms] SSH / Reusability / etc
> 
> >>>>> On Fri, 15 Apr 2005 12:45:11 -0400, Sam Hartman 
> <hartmans-ietf@mit.edu> said:
> 
> Sam> no.  It is OK to explore use of the ssh keys, although 
> I'm personally
> Sam> against it.  As an AD, you'd need to get the secsh wg's 
> cooperation.
> 
> Sam> Re use of the ssh protocol is clearly OK if you can make it
work.
> 
> I think there have been multiple people who have "almost" suggested
> using another protocols like TLS and SSH in such a way as to
bootstrap
> USM with the keys, and then dump the other transport since it was
only
> used to define keys.  IE, I think there are a number of people that
> want to functionally this:
> 
>   1) start SSH or TLS between a command generator (CG) and a command
>      receiver (CR), for example (obviously not limited to just CG/CR
>      pairs).  This would include user authentication in the process
>      (anything from Radius, SASL, SSH-keys, ... works here)
> 
>   2) once that secure "link" is open, steal its keys (Ks).
> 
>   3) close transport
> 
>   4) throw Ks into engines for CR/CG
> 
>   5) continue with SNMP/USM (over the standard transport port 161 or
>      whatever) using Ks and, um, some user name and engineID as yet
>      not well discussed.
> 
> I *think* people are hinting at this, but no one has stated it
clearly
> so I can't be sure.
> 
> 1) I really don't see the benefit in this.  You're starting up
>    perfectly secure transport that is actually more secure and
>    flexible than USM and then dumping it so you can fall back use
>    something that isn't needed.  I don't see how this is simpler
than
>    merely tunneling SNMP through TLS/SSH or whatever as DTLS wants
to
>    do.  Heck, you could even do USM processing of the resulting SNMP
>    packet that was tunneled if you wanted as long as you ignore the
>    results and the security model number was actually different.  I
>    won't go farther into this unless someone agrees that what I've
>    described is actually what they're wishing to do.
> 
> 2) this is, in fact, an out of band keying mechanism *not* a
>    encapsulated keying mechanism and I hope everyone sees that.
[not
>    that it couldn't be a solution, but there is a difference].
> 
> -- 
> Wes Hardaker
> Sparta, Inc.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 20:35:44 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13051;
	Fri, 15 Apr 2005 20:35:44 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMbS4-0003uk-Gc; Fri, 15 Apr 2005 20:46:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMb7R-0005BJ-4l; Fri, 15 Apr 2005 20:25:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMb7P-0005B0-Px
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 20:25:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12342
	for <isms@ietf.org>; Fri, 15 Apr 2005 20:25:02 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMbHh-0003Ng-Tc
	for isms@ietf.org; Fri, 15 Apr 2005 20:35:42 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3G0OswP030968; 
	Sat, 16 Apr 2005 00:24:54 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3G0OkKj022372; 
	Sat, 16 Apr 2005 00:24:53 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041517245305907 ; Fri, 15 Apr 2005 17:24:53 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 17:24:53 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 17:24:52 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Apr 2005 20:24:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Fri, 15 Apr 2005 20:24:28 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FA9AB5@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVB+1R8mal7usJYQqWwjTMfK9q1EQAGnVQAAAEbJEA=
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <ietfdbh@comcast.net>, "Wes Hardaker" <hardaker@tislabs.com>,
        "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 16 Apr 2005 00:24:51.0524 (UTC)
	FILETIME=[B486C040:01C5421A]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Content-Transfer-Encoding: quoted-printable

Dave H,

I think we're on the same page. I agree with all the 4 points you've
made.

Minor clarification: if using USM, then "securityName" would be the name
authenticated say, by RADIUS, and "usmUserName" would be an  ephemeral
name generated for this session. I mean, auditing based on ephemeral
names is harder than that based on the RADIUS-authenticated ones.

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of David B Harrington
Sent: Friday, April 15, 2005 5:12 PM
To: 'Wes Hardaker'; 'Sam Hartman'
Cc: isms@ietf.org
Subject: RE: [Isms] SSH / Reusability / etc

Hi,

So there is no ambiguity,=20

1) I do not support copying the keys from another protocol to stuff
into USM. I think that approach creates the potential for exposure of
the keys, which would weaken both protocols.

2) I can live with having the SNMP keys delivered to an SNMP security
model over a secure protocol, but that would not be my preference
because I think it creates the potential for exposure of the keys.
This could be slightly problematic remaining in sync with a
centralized server ( a fired operator whose credentials are removed
from RADIUS, might still have access to SNMP devices until the keys
were removed from the SNMP entity.)

3) My preference is to have SNMP be ignorant of the authentication
credentials used by another protocol, and to have that protocol simply
inform the SNMP security model of the authenticated user identity. The
security model might then dynamically stuff the securityname and other
necessary parameters into the USM MIB or a similar MIB so the SNMP
engine components can utilize the securityName to provide access
control, audit logging, etc. based on the securityName.

4) I would like to see the authentication server also provide
authorization information that ties into the VACM groupname table or a
similar approach to identifying which acceess control "policy" should
be applied for this security principal. I support the use of RADIUS or
other AAA server as one source for authorization policy.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: isms-bounces@lists.ietf.org=20
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker
> Sent: Friday, April 15, 2005 4:26 PM
> To: Sam Hartman
> Cc: isms@ietf.org
> Subject: Re: [Isms] SSH / Reusability / etc
>=20
> >>>>> On Fri, 15 Apr 2005 12:45:11 -0400, Sam Hartman=20
> <hartmans-ietf@mit.edu> said:
>=20
> Sam> no.  It is OK to explore use of the ssh keys, although=20
> I'm personally
> Sam> against it.  As an AD, you'd need to get the secsh wg's=20
> cooperation.
>=20
> Sam> Re use of the ssh protocol is clearly OK if you can make it
work.
>=20
> I think there have been multiple people who have "almost" suggested
> using another protocols like TLS and SSH in such a way as to
bootstrap
> USM with the keys, and then dump the other transport since it was
only
> used to define keys.  IE, I think there are a number of people that
> want to functionally this:
>=20
>   1) start SSH or TLS between a command generator (CG) and a command
>      receiver (CR), for example (obviously not limited to just CG/CR
>      pairs).  This would include user authentication in the process
>      (anything from Radius, SASL, SSH-keys, ... works here)
>=20
>   2) once that secure "link" is open, steal its keys (Ks).
>=20
>   3) close transport
>=20
>   4) throw Ks into engines for CR/CG
>=20
>   5) continue with SNMP/USM (over the standard transport port 161 or
>      whatever) using Ks and, um, some user name and engineID as yet
>      not well discussed.
>=20
> I *think* people are hinting at this, but no one has stated it
clearly
> so I can't be sure.
>=20
> 1) I really don't see the benefit in this.  You're starting up
>    perfectly secure transport that is actually more secure and
>    flexible than USM and then dumping it so you can fall back use
>    something that isn't needed.  I don't see how this is simpler
than
>    merely tunneling SNMP through TLS/SSH or whatever as DTLS wants
to
>    do.  Heck, you could even do USM processing of the resulting SNMP
>    packet that was tunneled if you wanted as long as you ignore the
>    results and the security model number was actually different.  I
>    won't go farther into this unless someone agrees that what I've
>    described is actually what they're wishing to do.
>=20
> 2) this is, in fact, an out of band keying mechanism *not* a
>    encapsulated keying mechanism and I hope everyone sees that.
[not
>    that it couldn't be a solution, but there is a difference].
>=20
> --=20
> Wes Hardaker
> Sparta, Inc.
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 20:54:04 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14112;
	Fri, 15 Apr 2005 20:54:04 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMbjo-0004sC-Si; Fri, 15 Apr 2005 21:04:45 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMbMe-0006lZ-Qg; Fri, 15 Apr 2005 20:40:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMbMc-0006lE-Uq
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 20:40:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13459
	for <isms@ietf.org>; Fri, 15 Apr 2005 20:40:45 -0400 (EDT)
Message-Id: <200504160040.UAA13459@ietf.org>
Received: from rwcrmhc14.comcast.net ([216.148.227.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMbWv-00049Q-8P
	for isms@ietf.org; Fri, 15 Apr 2005 20:51:25 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc14) with SMTP
	id <20050416004036014005pa60e>; Sat, 16 Apr 2005 00:40:36 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>,
        "'Wes Hardaker'" <hardaker@tislabs.com>,
        "'Sam Hartman'" <hartmans-ietf@mit.edu>
Subject: RE: [Isms] SSH / Reusability / etc
Date: Fri, 15 Apr 2005 20:40:30 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9AB5@pysmsx401.amr.corp.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVB+1R8mal7usJYQqWwjTMfK9q1EQAGnVQAAAEbJEAAAEs7AA==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd
Content-Transfer-Encoding: 7bit

Hi Uri,

It would help if you were more specific about "using USM" - My
comments were about using the USM MIB or a similar MIB. This is
distinct from using the USM processing rules.

The securityName would be a long-lived human-readable
security-model-independent identifier of the security principal, in a
mode similar to usmUserSecurityName. In your example, the securityname
might be the same as that stored in a RADIUS server to identify a
security principal (e.g. an employee name). This would be useful for
audit logging, and is required for the SNMPv3 ASIs.

If there is a session identifier or other ephemeral identifier, that
would be a model-specific identity in a manner similar to usmUserName.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] 
> Sent: Friday, April 15, 2005 8:24 PM
> To: ietfdbh@comcast.net; Wes Hardaker; Sam Hartman
> Cc: isms@ietf.org
> Subject: RE: [Isms] SSH / Reusability / etc
> 
> Dave H,
> 
> I think we're on the same page. I agree with all the 4 points you've
> made.
> 
> Minor clarification: if using USM, then "securityName" would 
> be the name
> authenticated say, by RADIUS, and "usmUserName" would be an
ephemeral
> name generated for this session. I mean, auditing based on ephemeral
> names is harder than that based on the RADIUS-authenticated ones.
> 
> -----Original Message-----
> From: isms-bounces@lists.ietf.org
[mailto:isms-bounces@lists.ietf.org]
> On Behalf Of David B Harrington
> Sent: Friday, April 15, 2005 5:12 PM
> To: 'Wes Hardaker'; 'Sam Hartman'
> Cc: isms@ietf.org
> Subject: RE: [Isms] SSH / Reusability / etc
> 
> Hi,
> 
> So there is no ambiguity, 
> 
> 1) I do not support copying the keys from another protocol to stuff
> into USM. I think that approach creates the potential for exposure
of
> the keys, which would weaken both protocols.
> 
> 2) I can live with having the SNMP keys delivered to an SNMP
security
> model over a secure protocol, but that would not be my preference
> because I think it creates the potential for exposure of the keys.
> This could be slightly problematic remaining in sync with a
> centralized server ( a fired operator whose credentials are removed
> from RADIUS, might still have access to SNMP devices until the keys
> were removed from the SNMP entity.)
> 
> 3) My preference is to have SNMP be ignorant of the authentication
> credentials used by another protocol, and to have that protocol
simply
> inform the SNMP security model of the authenticated user identity.
The
> security model might then dynamically stuff the securityname and
other
> necessary parameters into the USM MIB or a similar MIB so the SNMP
> engine components can utilize the securityName to provide access
> control, audit logging, etc. based on the securityName.
> 
> 4) I would like to see the authentication server also provide
> authorization information that ties into the VACM groupname table or
a
> similar approach to identifying which acceess control "policy"
should
> be applied for this security principal. I support the use of RADIUS
or
> other AAA server as one source for authorization policy.
> 
> David Harrington
> dbharrington@comcast.net
> 
> > -----Original Message-----
> > From: isms-bounces@lists.ietf.org 
> > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker
> > Sent: Friday, April 15, 2005 4:26 PM
> > To: Sam Hartman
> > Cc: isms@ietf.org
> > Subject: Re: [Isms] SSH / Reusability / etc
> > 
> > >>>>> On Fri, 15 Apr 2005 12:45:11 -0400, Sam Hartman 
> > <hartmans-ietf@mit.edu> said:
> > 
> > Sam> no.  It is OK to explore use of the ssh keys, although 
> > I'm personally
> > Sam> against it.  As an AD, you'd need to get the secsh wg's 
> > cooperation.
> > 
> > Sam> Re use of the ssh protocol is clearly OK if you can make it
> work.
> > 
> > I think there have been multiple people who have "almost"
suggested
> > using another protocols like TLS and SSH in such a way as to
> bootstrap
> > USM with the keys, and then dump the other transport since it was
> only
> > used to define keys.  IE, I think there are a number of people
that
> > want to functionally this:
> > 
> >   1) start SSH or TLS between a command generator (CG) and a
command
> >      receiver (CR), for example (obviously not limited to just
CG/CR
> >      pairs).  This would include user authentication in the
process
> >      (anything from Radius, SASL, SSH-keys, ... works here)
> > 
> >   2) once that secure "link" is open, steal its keys (Ks).
> > 
> >   3) close transport
> > 
> >   4) throw Ks into engines for CR/CG
> > 
> >   5) continue with SNMP/USM (over the standard transport port 161
or
> >      whatever) using Ks and, um, some user name and engineID as
yet
> >      not well discussed.
> > 
> > I *think* people are hinting at this, but no one has stated it
> clearly
> > so I can't be sure.
> > 
> > 1) I really don't see the benefit in this.  You're starting up
> >    perfectly secure transport that is actually more secure and
> >    flexible than USM and then dumping it so you can fall back use
> >    something that isn't needed.  I don't see how this is simpler
> than
> >    merely tunneling SNMP through TLS/SSH or whatever as DTLS wants
> to
> >    do.  Heck, you could even do USM processing of the resulting
SNMP
> >    packet that was tunneled if you wanted as long as you ignore
the
> >    results and the security model number was actually different.
I
> >    won't go farther into this unless someone agrees that what I've
> >    described is actually what they're wishing to do.
> > 
> > 2) this is, in fact, an out of band keying mechanism *not* a
> >    encapsulated keying mechanism and I hope everyone sees that.
> [not
> >    that it couldn't be a solution, but there is a difference].
> > 
> > -- 
> > Wes Hardaker
> > Sparta, Inc.
> > 
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Fri Apr 15 21:19:15 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16095;
	Fri, 15 Apr 2005 21:19:15 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMc8B-00066q-FH; Fri, 15 Apr 2005 21:29:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMbjs-0000Yr-02; Fri, 15 Apr 2005 21:04:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMbjq-0000Ye-3R
	for isms@megatron.ietf.org; Fri, 15 Apr 2005 21:04:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14897
	for <isms@ietf.org>; Fri, 15 Apr 2005 21:04:44 -0400 (EDT)
Message-Id: <200504160104.VAA14897@ietf.org>
Received: from rwcrmhc11.comcast.net ([204.127.198.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMbu8-0005Im-0P
	for isms@ietf.org; Fri, 15 Apr 2005 21:15:25 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc11) with SMTP
	id <2005041601043401300ki3rge>; Sat, 16 Apr 2005 01:04:35 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: <j.schoenwaelder@iu-bremen.de>,
        "'Blumenthal, Uri'" <uri.blumenthal@intel.com>
Subject: RE: [Isms] SSH / Reusability / etc
Date: Fri, 15 Apr 2005 21:04:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <20050415214346.GA879@boskop.local>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVCB1p41fxVKdbaSgKKc9lgpj7qxQAFaF8w
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: "'Sam Hartman'" <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit

 

Juergen Schoenwaelder said:
> 
> All you need to do is an authentication exchange once the secure 
> transport is open which gives you a securityName.

I concur. And the securityName could be utilized for the length of the
authenticated session.

While it might be possible to get a securityname from the transport
portocol (e.g. TLS), I think it unlikely that the transport protocol
can offer any authorization information for the tie-in to VACM.

I would prefer to see the authentication exchange done at layer 7,
followed by an authorization exchange to the same or different
mechanism. This may mean doing something like having the
transport/security model in the SNMP engine also serve as (or call) a
RADIUS client or a SASL client, after securing the message at the
transport layer.

David Harrington
dbharrington@comcast.net




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Sat Apr 16 04:01:27 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03155;
	Sat, 16 Apr 2005 04:01:27 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMiPT-0000fh-BV; Sat, 16 Apr 2005 04:12:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMi0S-0002p7-L9; Sat, 16 Apr 2005 03:46:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMi0Q-0002od-A9
	for isms@megatron.ietf.org; Sat, 16 Apr 2005 03:46:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02458
	for <isms@ietf.org>; Sat, 16 Apr 2005 03:46:16 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMiAk-00085J-OQ
	for isms@ietf.org; Sat, 16 Apr 2005 03:57:01 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 16 Apr 2005 00:46:07 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3G7k3hu028248;
	Sat, 16 Apr 2005 00:46:04 -0700 (PDT)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp12.cisco.com [10.61.64.12])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3G7bJKU031495;
	Sat, 16 Apr 2005 00:37:20 -0700
Message-ID: <4260C2B9.6070005@cisco.com>
Date: Sat, 16 Apr 2005 09:46:01 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] SSH / Reusability / etc
References: <3DEC199BD7489643817ECA151F7C5929FA9A22@pysmsx401.amr.corp.intel.com>
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FA9A22@pysmsx401.amr.corp.intel.com>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113637041.520416"; x:"432200"; a:"rsa-sha1"; b:"nofws:545";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"AsO7QbVLbH0aAnrz3x7vHsAzIBZoQBTG7wdf3KuEuNt16uH4c680iG4qa8iQnUJXdl3igueH"
	"fv1yl3RC+kRAYHRQQsP+SXFkhlmBASyqAFYrRsCPp+FuGoVlW43W/zIn9AVtembOSOUzQjceVPs"
	"L0ByxE2E4b70PkKqHvmcjIZE=";
	c:"Date: Sat, 16 Apr 2005 09:46:01 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: [Isms] SSH / Reusability / etc"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit

I'm not an SNMP expert and CERTAINLY NOT an expert on VACM, but...

Blumenthal, Uri wrote:
> 3. Somehow invoke TLS or SSH, tunnel SNMP messages through it, somehow
> for every packet get the mapping to VACM. Unless "somehow" is replaced
> by something tangible and aceptable, I don't like this approach.

Why wouldn't this simply be a new <securityModel, securityName> tuple? 
You'd probably have to use SASL w/ TLS because securityName is limited 
to SnmpAdminString(1..32), and OBTW you get that externally.  Were I to 
do this I would perform substantial surgey on the command so that 
securityNames are not sent with every command to avoid conflicts.

Eliot

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@ietf.org  Sat Apr 16 07:12:07 2005
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12791;
	Sat, 16 Apr 2005 07:12:06 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DMlO2-0000dv-G6; Sat, 16 Apr 2005 07:22:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMl3j-0002Cg-Fs; Sat, 16 Apr 2005 07:01:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMl3i-0002CP-A0
	for isms@megatron.ietf.org; Sat, 16 Apr 2005 07:01:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12347
	for <isms@ietf.org>; Sat, 16 Apr 2005 07:01:51 -0400 (EDT)
Message-Id: <200504161101.HAA12347@ietf.org>
Received: from rwcrmhc14.comcast.net ([216.148.227.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMlE6-0000NN-Fv
	for isms@ietf.org; Sat, 16 Apr 2005 07:12:38 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc14) with SMTP
	id <20050416110144014005lh9fe>; Sat, 16 Apr 2005 11:01:44 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Eliot Lear'" <lear@cisco.com>,
        "'Blumenthal, Uri'" <uri.blumenthal@intel.com>
Subject: RE: [Isms] SSH / Reusability / etc
Date: Sat, 16 Apr 2005 07:01:34 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <4260C2B9.6070005@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVCWn4Ze7fOzv7FTB6TndIGswKqfwAFyIbQ
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: "'Sam Hartman'" <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit

Hi Eliot,

I think I agree with you (mostly), but I need to have you help me
understand what you're saying.

What is OBTW? I'm not sure if the presence of the term here impacts
the semantics of the sentence. I could assume it means oh-by-the-way,
and simply remove it from the sentence, but OBTW might mean something
that would seriously change the meaning of the sentence.

I can't fully comprehend the impact of "substantial surgery on the
command"
What command are you referring to?
I understand there is substantial work to be done; did you have
specific surgery in mind?

Dbh

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Eliot Lear
> Sent: Saturday, April 16, 2005 3:46 AM
> To: Blumenthal, Uri
> Cc: Sam Hartman; isms@ietf.org
> Subject: Re: [Isms] SSH / Reusability / etc
> 
> I'm not an SNMP expert and CERTAINLY NOT an expert on VACM, but...
> 
> Blumenthal, Uri wrote:
> > 3. Somehow invoke TLS or SSH, tunnel SNMP messages through 
> it, somehow
> > for every packet get the mapping to VACM. Unless "somehow" 
> is replaced
> > by something tangible and aceptable, I don't like this approach.
> 
> Why wouldn't this simply be a new <securityModel, 
> securityName> tuple? 
> You'd probably have to use SASL w/ TLS because securityName 
> is limited 
> to SnmpAdminString(1..32), and OBTW you get that externally.  
> Were I to 
> do this I would perform substantial surgey on the command so that 
> securityNames are not sent with every command to avoid conflicts.
> 
> Eliot
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


From isms-bounces@lists.ietf.org Sat Apr 16 15:15:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMsli-0006Ve-K0; Sat, 16 Apr 2005 15:15:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMslh-0006V0-SV
	for isms@megatron.ietf.org; Sat, 16 Apr 2005 15:15:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25786
	for <isms@ietf.org>; Sat, 16 Apr 2005 15:15:45 -0400 (EDT)
Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMsUq-0003sP-Cb
	for isms@ietf.org; Sat, 16 Apr 2005 14:58:24 -0400
Received: from h-68-165-3-75.snvacaid.dynamic.covad.net ([68.165.3.75]
	helo=oemcomputer)
	by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DMsKL-0005jZ-00
	for isms@ietf.org; Sat, 16 Apr 2005 11:47:33 -0700
Message-ID: <000801c542b4$f788a080$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <3DEC199BD7489643817ECA151F7C5929FA9A22@pysmsx401.amr.corp.intel.com>
	<4260C2B9.6070005@cisco.com>
Subject: Re: [Isms] SSH / Reusability / etc
Date: Sat, 16 Apr 2005 11:49:05 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi -

> From: "Eliot Lear" <lear@cisco.com>
> To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
> Cc: "Sam Hartman" <hartmans-ietf@mit.edu>; <isms@ietf.org>
> Sent: Saturday, April 16, 2005 12:46 AM
> Subject: Re: [Isms] SSH / Reusability / etc
>

> I'm not an SNMP expert and CERTAINLY NOT an expert on VACM, but...
>
> Blumenthal, Uri wrote:
> > 3. Somehow invoke TLS or SSH, tunnel SNMP messages through it, somehow
> > for every packet get the mapping to VACM. Unless "somehow" is replaced
> > by something tangible and aceptable, I don't like this approach.
>
> Why wouldn't this simply be a new <securityModel, securityName> tuple?
...

Not quite, if the objective is to minimize the number of systems that need
to be touched whenever a new user is added or deleted.
There are two mappings of interest:
    1) the security-model-specific-name -> the security-model-neutral-name
    2) the security-model-neutral-name -> the group-name used in vacm

One could skirt around the first by specifying that for this particular security
model, the name that is carried in protocol is the model-neutral name, though
it makes things tougher when federating.
The second is needed to associate that particular user with the set of
users with identical permissions.  Without it, the user cannot access
anything.

The name->group mapping could be obtained several ways:
    a) pre-provisioned by configuring the user to group table in VACM.
        This is how things work today, and has the disadvantage that whenever
        a new user is added, one has to touch all the managed systems that
        that user might need to access.
    b) obtained in real time by the snmp engine  asking some
        system that can securely supply these mappings
    c) supplied by some system *telling* the snmp engine
        what it will need to know before the snmp engine receives the request.
        (This is a generalization of (a) to include other protocols.)
    d) carried along with the request.  This information would have to be
        signed/certified in some way, since we'd hardly trust users to choose
        their own groups.

For *all* of these options, I think there is value to providing a mechanism
to limit the lifetime of the user->group entry.  This reduces the need to
touch managed systems when users are removed or their privileges
are revoked, and could also make managed systems a little more resistant
to some off-line attacks.

> You'd probably have to use SASL w/ TLS because securityName is limited
> to SnmpAdminString(1..32), and OBTW you get that externally.  Were I to
> do this I would perform substantial surgey on the command so that
> securityNames are not sent with every command to avoid conflicts.
...

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 16 19:44:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DMwxQ-0006Yk-3q; Sat, 16 Apr 2005 19:44:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DMwxO-0006YF-3i
	for isms@megatron.ietf.org; Sat, 16 Apr 2005 19:44:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19014
	for <isms@ietf.org>; Sat, 16 Apr 2005 19:44:08 -0400 (EDT)
Received: from moby.atcorp.com ([204.72.172.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMx7s-000400-O2
	for isms@ietf.org; Sat, 16 Apr 2005 19:55:01 -0400
Received: from conger.atcorp.com ([204.72.172.102] helo=STRIPER)
	by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian))
	id 1DMwxE-0001Uc-00
	for <isms@ietf.org>; Sat, 16 Apr 2005 18:44:00 -0500
From: "Wayne Kading" <wkading@atcorp.com>
To: <isms@ietf.org>
Subject: RE: [Isms] YAAP (Yet Another Architecture Proposal) - Localized PSK
	Auth
Date: Sat, 16 Apr 2005 18:43:58 -0500
Organization: ATC
Message-ID: <003101c542de$29798590$84aca8c0@STRIPER>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <BC5CFB047387BD41AC606027302F1FDD13F69A@xmb-sjc-22e.amer.cisco.com>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi,

The proposed LPSK architecture has some appealing points.  I'm curious to
know how this fits into our architecture evaluation or if any beneficial
parts can be used in the existing proposals.  I would be interested in
hearing some feedback from the WG on the perceived pros/cons of the LPSK
proposal.

Wayne

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Khanh Nguyen (khanhvn)
Sent: Friday, April 15, 2005 1:16 PM
To: isms@ietf.org
Subject: [Isms] YAAP (Yet Another Architecture Proposal) - Localized PSK
Auth

...

Hi All,

I am new to this ISMS mailing list and would like to share some thoughts
that I had recently about SNMPv3. Attached please find a proposal to use
localized pre-shared keys for SNMPv3 authentication. This is a
preliminary draft so sorry if some details are missing. 

The main points of the proposal are:

1. Decouple authentication from data integrity and confidentiality.

2. Data integrity and confidentiality are to be done at the transport
layer (e.g. TLS), similar to the TMSM proposal.

3. Authentication to be done at SNMP application level (on top of a
secure transport).

4. <user ID+password+snmpEngine ID> are used to generate localized
pre-shared keys (LPSK), which are then used to certify the credentials
of the users as well as SNMP devices.

5. A PSK protocol (such as SRP) over a secure transport (e.g. TLS) uses
LPSK-based credentials to authenticate users and devices. No external
auth infrastructure is needed (other than one to configure users and/or
community strings.)

This proposal is an abstract model and does not specify any protocol
selections. I hope that it can be used as a starting point for a new
SNMPv3 authentication model that is secure, simple, and flexible. Your
comments and suggestions will be greatly appreciated.

I'd like to thank Kaushik Narayan and Keith McCloghrie for their early
comments on the proposal. (This is not to say that they endorse it.)

Khanh 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 03:19:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DN44D-00014q-7s; Sun, 17 Apr 2005 03:19:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DN44A-00014h-Fs
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 03:19:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29303
	for <isms@ietf.org>; Sun, 17 Apr 2005 03:19:36 -0400 (EDT)
Received: from i9d2e.i.pppool.de ([85.73.157.46] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DN4Eh-0003cK-Oy
	for isms@ietf.org; Sun, 17 Apr 2005 03:30:33 -0400
Received: by boskop.local (Postfix, from userid 501)
	id 7CD0427E70E; Sun, 17 Apr 2005 09:19:21 +0200 (CEST)
Date: Sun, 17 Apr 2005 09:19:19 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Wayne Kading <wkading@atcorp.com>
Subject: Re: [Isms] YAAP (Yet Another Architecture Proposal) - Localized PSK
	Auth
Message-ID: <20050417071919.GC1781@boskop.local>
Mail-Followup-To: Wayne Kading <wkading@atcorp.com>, isms@ietf.org
References: <BC5CFB047387BD41AC606027302F1FDD13F69A@xmb-sjc-22e.amer.cisco.com>
	<003101c542de$29798590$84aca8c0@STRIPER>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003101c542de$29798590$84aca8c0@STRIPER>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

On Sat, Apr 16, 2005 at 06:43:58PM -0500, Wayne Kading wrote:
 
> The proposed LPSK architecture has some appealing points.  I'm curious to
> know how this fits into our architecture evaluation or if any beneficial
> parts can be used in the existing proposals.  I would be interested in
> hearing some feedback from the WG on the perceived pros/cons of the LPSK
> proposal.

My understanding is that LPSK is an instantiation of TLSM. BTW, does
someone know here what happened to the SRP SASL? There was an ID called
</draft-burdis-cat-srp-sasl-09.txt> which seems to have disappeared.

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 03:41:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DN4Pa-00037A-88; Sun, 17 Apr 2005 03:41:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DN4PX-000374-QA
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 03:41:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00193
	for <isms@ietf.org>; Sun, 17 Apr 2005 03:41:41 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DN4a5-0004fO-MR
	for isms@ietf.org; Sun, 17 Apr 2005 03:52:39 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-1.cisco.com with ESMTP; 17 Apr 2005 00:41:33 -0700
X-IronPort-AV: i="3.92,106,1112598000"; 
	d="scan'208"; a="629656571:sNHT28472084"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3H7fRKx025838;
	Sun, 17 Apr 2005 00:41:27 -0700 (PDT)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp4262.cisco.com [10.61.80.165])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3H7Wf2X002142;
	Sun, 17 Apr 2005 00:32:42 -0700
Message-ID: <42621328.8040505@cisco.com>
Date: Sun, 17 Apr 2005 09:41:28 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietfdbh@comcast.net
Subject: Re: [Isms] SSH / Reusability / etc
References: <40ql7s$1l3pf5@sj-inbound-c.cisco.com>
In-Reply-To: <40ql7s$1l3pf5@sj-inbound-c.cisco.com>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113723163.846882"; x:"432200"; a:"rsa-sha1"; b:"nofws:437";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"ITiKoxuW0DTd19sH4tcEV08EA74l2DL0xVVoGhNgxRQwBFElMrN1W0GKY5/THQQ3LA2IXlaA"
	"DtROkJaxYDN1ugRfqnX6rSaytny/CDtV7iznseEdkKXnPuWPD1HypxR0FH2DQCmxHnmzId/d4Zr"
	"Htjp+f3QBF8MnHq8vko3drkk=";
	c:"Date: Sun, 17 Apr 2005 09:41:28 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: [Isms] SSH / Reusability / etc"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: 'Sam Hartman' <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Dave,

You're exactly correct that OBTW means Oh By The Way.  The substantial 
surgery that would need to be done is that if you are authenticating 
against the thing you are tunneling into (say, SSH keys with SSH or SASL 
or TLS with something else like BEEP), I do not think it a good idea to 
retransmit any additional authentication information in the encapsulated 
SNMP PDU.  In other words, what would happen if the SSH user 
authenticates as "eliot" and the PDU contains "dave"?  That shouldn't 
happen.

That's all I'm saying.

Eliot

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 06:42:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DN7EC-0002a2-Bw; Sun, 17 Apr 2005 06:42:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DN7EC-0002Zx-1v
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 06:42:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09518
	for <isms@ietf.org>; Sun, 17 Apr 2005 06:42:08 -0400 (EDT)
Received: from thoth.sbs.de ([192.35.17.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DN7Ol-0000re-3T
	for isms@ietf.org; Sun, 17 Apr 2005 06:53:08 -0400
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j3HAg4Ym002193
	for <isms@ietf.org>; Sun, 17 Apr 2005 12:42:04 +0200
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3HAg4qL028215
	for <isms@ietf.org>; Sun, 17 Apr 2005 12:42:04 +0200
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72)
	id <2SQ5LWCC>; Sun, 17 Apr 2005 12:42:04 +0200
Message-ID: <D2E490BD3F24C24598C4605E40024D15189128@mchp9gma.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: isms@ietf.org
Date: Sun, 17 Apr 2005 12:39:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: 
Subject: [Isms] TLS Inner Application Extension
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

hi all, 

may i draw your attention to the following document that might be relevant
for your work:
http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extensi
on-01.txt

as a short summary: it integrates the extensible authentication protocol
(eap) into the tls handshake.

i personally think that this provides much better properties than the
proposal of carrying sasl over tls (as proposed in 
<draft-schoenw-snmp-tlsm-01.txt>). 

ciao
hannes

ps: when reading <draft-schoenw-snmp-tlsm-01.txt> i recognized that tls-psk
<draft-ietf-tls-psk-07.txt> is not mentioned.
i would, however, fit quite nicely into the whole picture. 

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 07:24:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DN7tB-0006h2-K0; Sun, 17 Apr 2005 07:24:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DN7t9-0006gx-TS
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 07:24:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11430
	for <isms@ietf.org>; Sun, 17 Apr 2005 07:24:30 -0400 (EDT)
Received: from david.siemens.de ([192.35.17.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DN83k-00034A-Lu
	for isms@ietf.org; Sun, 17 Apr 2005 07:35:29 -0400
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by david.siemens.de (8.12.6/8.12.6) with ESMTP id j3HBOPZH016868;
	Sun, 17 Apr 2005 13:24:25 +0200
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3HBOPwl007087;
	Sun, 17 Apr 2005 13:24:25 +0200
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72)
	id <2SQ5LW1G>; Sun, 17 Apr 2005 13:24:25 +0200
Message-ID: <D2E490BD3F24C24598C4605E40024D15189129@mchp9gma.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>, Martin Soukup <msoukup@nortel.com>
Subject: AW: [Isms] RADIUS is not a trusted third party
Date: Sun, 17 Apr 2005 13:21:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

hi sam,=20

you have intentionally chosen a provocative title for your mail.=20

you write:

"
> Remember that RADIUS is a callout service; it is not a trusted third
> party.  In other words, in a particular SNMP authentication, only one
> of the parties will know that RADIUS is being used.
"

what is a "callout service"?
what is radius for you? (you write that it is not a trusted third =
party.)
why do you care that only one party knows that radius is used? it could =
also
be diameter.=20

i would like to better understand why some people dislike the aaa
architecture (radius, diameter).

ciao
hannes


> -----Urspr=FCngliche Nachricht-----
> Von: isms-bounces@lists.ietf.org=20
> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman
> Gesendet: Freitag, 15. April 2005 19:34
> An: Martin Soukup
> Cc: isms@ietf.org
> Betreff: [Isms] RADIUS is not a trusted third party
>=20
>=20
> >>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:
>=20
>     Martin> RADIUS "Access-Accept" indicates a successful
>     Martin> authenthentication response for a user.
>=20
>     Martin> The Access-Accept already returns a "Session-Timeout",
>     Martin> defined as "Sets the maximum number of seconds of service
>     Martin> to be provided to the user before the session
>     Martin> terminates. This attribute value becomes the per-user
>     Martin> "absolute timeout."".
>=20
> This only tells the SNMP engine talking to the RADIUS server the
> timeout.  You need to tell the other side of the exchange the timeout
> too.
>=20
> Remember that RADIUS is a callout service; it is not a trusted third
> party.  In other words, in a particular SNMP authentication, only one
> of the parties will know that RADIUS is being used.
>=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 07:26:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DN7vK-0006x0-Uk; Sun, 17 Apr 2005 07:26:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DN7vI-0006wv-Sj
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 07:26:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11505
	for <isms@ietf.org>; Sun, 17 Apr 2005 07:26:43 -0400 (EDT)
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DN85s-0003BC-Rr
	for isms@ietf.org; Sun, 17 Apr 2005 07:37:42 -0400
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j3HBPZU3013056;
	Sun, 17 Apr 2005 13:25:35 +0200
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3HBPZXj007292;
	Sun, 17 Apr 2005 13:25:35 +0200
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72)
	id <2SQ5LW1K>; Sun, 17 Apr 2005 13:25:35 +0200
Message-ID: <D2E490BD3F24C24598C4605E40024D1518912A@mchp9gma.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: "'Kaushik Narayan'" <kaushik@cisco.com>, isms@ietf.org
Subject: AW: [Isms] USM Protection vs Transport Protection
Date: Sun, 17 Apr 2005 13:23:07 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

hi kaushik,=20

it is true that the type of protection has an impact on solution (at =
least
with what most protocols provide today).
however, i think that this issue is the least difficult one. once you =
have
the session keys and the algorithms in place it is really easy to =
protect
the messages using standard mechanisms.=20

a more difficult part is to decide on the key management part.

ciao
hannes


> -----Urspr=FCngliche Nachricht-----
> Von: isms-bounces@lists.ietf.org=20
> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Kaushik Narayan
> Gesendet: Freitag, 15. April 2005 23:49
> An: isms@ietf.org
> Betreff: [Isms] USM Protection vs Transport Protection
>=20
>=20
> Hi All,
>=20
> Having gone through the discussion of architectural
> choices, I think the first decision that we might want
> to make is whether we need continue to use USM for
> message protection vs. using some other protection
> mechanism such as the transport protection suggested
> by TLSM.
>=20
> regards,
>    kaushik!
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 14:11:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNEDq-0002Eu-BP; Sun, 17 Apr 2005 14:10:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNEDo-0002Du-7v
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 14:10:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10644
	for <isms@ietf.org>; Sun, 17 Apr 2005 14:10:14 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNEOS-0000Fz-Sr
	for isms@ietf.org; Sun, 17 Apr 2005 14:21:17 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-5.cisco.com with ESMTP; 17 Apr 2005 11:10:07 -0700
Received: from gwzw2k01 (sjc-vpn5-809.cisco.com [10.21.91.41])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3HI9spR022495;
	Sun, 17 Apr 2005 11:09:55 -0700 (PDT)
Message-Id: <200504171809.j3HI9spR022495@sj-core-4.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Tschofenig Hannes'" <hannes.tschofenig@siemens.com>,
	"'Sam Hartman'" <hartmans-ietf@mit.edu>,
	"'Martin Soukup'" <msoukup@nortel.com>
Subject: RE: [Isms] RADIUS is not a trusted third party
Date: Sun, 17 Apr 2005 11:09:54 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVDQB38XlEUMWIdSW+oZx+4HW0FIAAM+0kg
In-Reply-To: <D2E490BD3F24C24598C4605E40024D15189129@mchp9gma.mch.sbs.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Tschofenig Hannes <> supposedly scribbled:

> hi sam,
>=20
> you have intentionally chosen a provocative title for your mail.
>=20
> you write:
>=20
> "
>> Remember that RADIUS is a callout service; it is not a trusted
third
>> party.  In other words, in a particular SNMP authentication, only
one
>> of the parties will know that RADIUS is being used. "
>=20
> what is a "callout service"?
> what is radius for you? (you write that it is not a trusted third
> party.)=20

It's not.  From the point of view of authentication protocols (PAP,
CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": the
operation of the auth protocols should be exactly the same as if
they terminated in the AAA client, instead of elsewhere.  Basically,
the purpose of AAA (again, from the POV of an authentication
protocol) is simply scaling.  BTW, a lot of misery has been caused
by the erroneous belief that EAP is (or can be) a three-party
authentication protocol: it isn't, and can't be.  It could _carry_ a
three-party protocol (like Kerberos), but EAP in itself is a
two-party protocol.

> why do you care that only one party knows that radius is
> used? it could also be diameter. =20
>=20
> i would like to better understand why some people dislike the aaa
> architecture (radius, diameter).=20

I think that the misunderstanding mentioned above might have
something to do with it...

>=20
> ciao
> hannes
>=20
>=20
>> -----Urspr=FCngliche Nachricht-----
>> Von: isms-bounces@lists.ietf.org
>> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman
>> Gesendet: Freitag, 15. April 2005 19:34
>> An: Martin Soukup
>> Cc: isms@ietf.org
>> Betreff: [Isms] RADIUS is not a trusted third party
>>=20
>>=20
>>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:
>>=20
>>     Martin> RADIUS "Access-Accept" indicates a successful
>>     Martin> authenthentication response for a user.
>>=20
>>     Martin> The Access-Accept already returns a
"Session-Timeout",
>>     Martin> defined as "Sets the maximum number of seconds of
service
>>     Martin> to be provided to the user before the session
>>     Martin> terminates. This attribute value becomes the per-user
>>     Martin> "absolute timeout."".
>>=20
>> This only tells the SNMP engine talking to the RADIUS server the
>> timeout.  You need to tell the other side of the exchange the
>> timeout too.=20
>>=20
>> Remember that RADIUS is a callout service; it is not a trusted
third
>> party.  In other words, in a particular SNMP authentication, only
one
>> of the parties will know that RADIUS is being used.
>>=20
>>=20
>> _______________________________________________
>> Isms mailing list
>> Isms@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/isms
>>=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 14:57:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNExa-0005jX-IV; Sun, 17 Apr 2005 14:57:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNExY-0005jS-DM
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 14:57:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13093
	for <isms@ietf.org>; Sun, 17 Apr 2005 14:57:30 -0400 (EDT)
Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNF8C-0001r5-8h
	for isms@ietf.org; Sun, 17 Apr 2005 15:08:33 -0400
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com
	[172.29.225.253])
	by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3HIujXd003464;
	Sun, 17 Apr 2005 11:56:45 -0700 (PDT)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service
	(5.5.2657.72) id <2R3A2Z7X>; Sun, 17 Apr 2005 11:56:45 -0700
Message-ID: <CFEE79A465B35C4385389BA5866BEDF00C7B66@mailsrvnt02.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'j.schoenwaelder@iu-bremen.de'" <j.schoenwaelder@iu-bremen.de>,
	Wayne Kading <wkading@atcorp.com>
Subject: RE: [Isms] YAAP (Yet Another Architecture Proposal) - Localized P
	SK Auth
Date: Sun, 17 Apr 2005 11:56:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi,

<draft-burdis-cat-srp-sasl-nn.txt> is marked as an expired I-D
with the following contact info:


For more information or a copy of the document, contact the author directly.

Draft Author(s):

K. Burdis: cskb@cs.ru.ac.za
R. Naffah: raif@forge.com.au

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org]On
> Behalf Of Juergen Schoenwaelder
> Sent: Sunday, April 17, 2005 3:19 AM
> To: Wayne Kading
> Cc: isms@ietf.org
> Subject: Re: [Isms] YAAP (Yet Another Architecture Proposal) 
> - Localized
> PSK Auth
> 
> 
> On Sat, Apr 16, 2005 at 06:43:58PM -0500, Wayne Kading wrote:
>  
> > The proposed LPSK architecture has some appealing points.  
> I'm curious to
> > know how this fits into our architecture evaluation or if 
> any beneficial
> > parts can be used in the existing proposals.  I would be 
> interested in
> > hearing some feedback from the WG on the perceived 
> pros/cons of the LPSK
> > proposal.
> 
> My understanding is that LPSK is an instantiation of TLSM. BTW, does
> someone know here what happened to the SRP SASL? There was an 
> ID called
> </draft-burdis-cat-srp-sasl-09.txt> which seems to have disappeared.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 15:32:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNFVB-0008IQ-UK; Sun, 17 Apr 2005 15:32:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFV9-0008IL-Su
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 15:32:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16212
	for <isms@ietf.org>; Sun, 17 Apr 2005 15:32:13 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNFfp-00048S-8o
	for isms@ietf.org; Sun, 17 Apr 2005 15:43:17 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 58599E0065; Sun, 17 Apr 2005 15:32:14 -0400 (EDT)
To: Tschofenig Hannes <hannes.tschofenig@siemens.com>
Subject: Re: AW: [Isms] RADIUS is not a trusted third party
References: <D2E490BD3F24C24598C4605E40024D15189129@mchp9gma.mch.sbs.de>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Sun, 17 Apr 2005 15:32:14 -0400
In-Reply-To: <D2E490BD3F24C24598C4605E40024D15189129@mchp9gma.mch.sbs.de>
	(Tschofenig Hannes's message of "Sun, 17 Apr 2005 13:21:49 +0200")
Message-ID: <tslmzrxurlt.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Tschofenig" == Tschofenig Hannes <hannes.tschofenig@siemens.com> writes:

    Tschofenig> hi sam, you have intentionally chosen a provocative
    Tschofenig> title for your mail.

Or at least a title designed to catch people's attention and make sure
we resolve this issue.


    Tschofenig> you write:

    Tschofenig> "
    >> Remember that RADIUS is a callout service; it is not a trusted
    >> third party.  In other words, in a particular SNMP
    >> authentication, only one of the parties will know that RADIUS
    >> is being used.
    Tschofenig> "

    Tschofenig> what is a "callout service"?  what is radius for you?

It is a service used by one party (typically the command responder for
SNMP) in order to improve the scaling properties of the authentication
infrastructure and avoid storing credentials in each command
responder.  I.E.  it is a service that the command responder uses to
call out to instead of performing some functions locally.



    Tschofenig> (you write that it is not a trusted third party.)  

Note that I don't mean that RADIUS should not be trusted.  Trusted
third party is a term of art in security and RADIUS as it is intended
to be used does not meet the definition of that term.

    Tschofenig> why
    Tschofenig> do you care that only one party knows that radius is
    Tschofenig> used? it could also be diameter.

You bring up one of the obvious reasons yourself.  If both parties
know RADIUS is used that means that the use of RADIUS has entered into
the protocol between those two parties.  That makes it hard for me to
use something else instead like diameter or tacacs+.  Another concern
is that if both parties need to know RADIUS is being used it probably
means that RADIUS is being misused.

    Tschofenig> i would like to better understand why some people
    Tschofenig> dislike the aaa architecture (radius, diameter).

With properly design EAP methods I think AAA can be fine.  RADIUS
traditionally has weak protection of its messages but that is not an
inherent flaw with AAA.  So I don't think I can present a good
argument that AAA is architecturally flawed because I don't believe
such an argument.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 15:35:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNFYQ-00004z-Dz; Sun, 17 Apr 2005 15:35:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFYP-00004u-5R
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 15:35:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16402
	for <isms@ietf.org>; Sun, 17 Apr 2005 15:35:35 -0400 (EDT)
Received: from stratton-four-twenty.mit.edu ([18.187.6.165]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNFj4-0004OU-Le
	for isms@ietf.org; Sun, 17 Apr 2005 15:46:38 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 7FF1AE0065; Sun, 17 Apr 2005 15:35:32 -0400 (EDT)
To: Eliot Lear <lear@cisco.com>
Subject: Re: [Isms] SSH / Reusability / etc
References: <40ql7s$1l3pf5@sj-inbound-c.cisco.com> <42621328.8040505@cisco.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Sun, 17 Apr 2005 15:35:32 -0400
In-Reply-To: <42621328.8040505@cisco.com> (Eliot Lear's message of "Sun, 17
	Apr 2005 09:41:28 +0200")
Message-ID: <tslis2lurgb.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Eliot" == Eliot Lear <lear@cisco.com> writes:

    Eliot> Dave, You're exactly correct that OBTW means Oh By The Way.
    Eliot> The substantial surgery that would need to be done is that
    Eliot> if you are authenticating against the thing you are
    Eliot> tunneling into (say, SSH keys with SSH or SASL or TLS with
    Eliot> something else like BEEP), I do not think it a good idea to
    Eliot> retransmit any additional authentication information in the
    Eliot> encapsulated SNMP PDU.  In other words, what would happen
    Eliot> if the SSH user authenticates as "eliot" and the PDU
    Eliot> contains "dave"?  That shouldn't happen.

Sure it should happen if the authentication level identity elliot is
allowed to act as the SNMP-level identity dave.  You need to have an
authorization level mapping for this, but the apps community has found
that allowing such proxy authorization is often useful.

There's a discussion of this concept in draft-ietf-sasl-rfc2222bis but
the working group seems to believe that discussion needs more work so
it may not be as clear as you would like.


Also, note that SASL has its own mechanism for conveying the inner
identity.  So if you were using SASL you might want to decide that you
didn't need an identity in the SNMP PDU.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 15:49:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNFlQ-00012q-GW; Sun, 17 Apr 2005 15:49:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFlO-00012l-I3
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 15:49:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17032
	for <isms@ietf.org>; Sun, 17 Apr 2005 15:49:00 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNFw1-0004xS-UE
	for isms@ietf.org; Sun, 17 Apr 2005 16:00:04 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DNFlJ-0005qG-PD; Sun, 17 Apr 2005 15:48:57 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3HJmtZ02953;
	Sun, 17 Apr 2005 12:48:55 -0700
Date: Sun, 17 Apr 2005 12:48:55 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: "Glen Zorn (gwz)" <gwz@cisco.com>
Subject: RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <200504171809.j3HI9spR022495@sj-core-4.cisco.com>
Message-ID: <Pine.LNX.4.56.0504171231330.1721@internaut.com>
References: <200504171809.j3HI9spR022495@sj-core-4.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: radiusext@ops.ietf.org, 'Sam Hartman' <hartmans-ietf@mit.edu>,
	isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> It's not.  From the point of view of authentication protocols (PAP,
> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": the
> operation of the auth protocols should be exactly the same as if
> they terminated in the AAA client, instead of elsewhere.  Basically,
> the purpose of AAA (again, from the POV of an authentication
> protocol) is simply scaling.  BTW, a lot of misery has been caused
> by the erroneous belief that EAP is (or can be) a three-party
> authentication protocol: it isn't, and can't be.  It could _carry_ a
> three-party protocol (like Kerberos), but EAP in itself is a
> two-party protocol.
>
> > why do you care that only one party knows that radius is
> > used? it could also be diameter.
> >
> > i would like to better understand why some people dislike the aaa
> > architecture (radius, diameter).
>
> I think that the misunderstanding mentioned above might have
> something to do with it...

As Glen said, EAP is a two-party protocol (run between EAP peer and
server).  RADIUS is also a two party protocol (between the authenticator
and server).  The system may also include a protocol run between the peer
and authenticator (the Secure Association Protocol).

An application has the flexibility to define new AAA attributes
(e.g. Diameter EAP); to define requirements with respect to EAP methods
(e.g. RFC 4017); and to define the Secure Association Protocol
(e.g. 802.11i 4-way handshake).

This flexibility is both a blessing and a curse.  It is a blessing in
that there is a lot of flexibility available to meet requirements if they
are well defined.  It is a curse because a key management application
needs to do considerable work in defining and analyzing the security
properties of the system in order to meet the security requirements
described in RFC 4017 (the Housley Criteria).

To enable analysis, the specification needs to detail the required AAA
protocol and EAP method properties as well as to define the security
properties of the Secure Association Protocol.  The best existing example
of this to date is probably IEEE 802.11i, but even that effort left out
some important pieces.

Note that the ISMS charter explicitly mentions RADIUS support:

"Version 3 of the Simple Network Management Protocol (SNMPv3) was
elevated to Internet Standard in late 2002 and added security to the
previous versions of the protocol. Although the enhanced protocol
is secure, operators and administrators find that deploying it can
be problematic in large distributions. This is due primarily to two
synchronization problems. The first is the addition of yet another
authentication system specific to SNMPv3 that needs to be maintained
across all networking devices. Most of these devices already
contain local accounts and/or the ability to negotiate with
authentication servers (e.g. RADIUS servers). However, SNMPv3 does
not make use of these authentication mechanisms, and this causes
additional synchronization burdens. The second issue found with
deploying SNMPv3 is that distributing and maintaining View-based
Access Control Model (VACM) rules is also difficult in large-scale
environments."

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 16:32:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNGRE-0004LM-Gq; Sun, 17 Apr 2005 16:32:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGRD-0004LE-F1
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 16:32:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19466
	for <isms@ietf.org>; Sun, 17 Apr 2005 16:32:13 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNGbs-0007hE-9p
	for isms@ietf.org; Sun, 17 Apr 2005 16:43:17 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 4836211DA2E; Sun, 17 Apr 2005 13:32:12 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] SSH / Reusability / etc
Organization: Sparta
References: <40ql7s$1l3pf5@sj-inbound-c.cisco.com>
	<42621328.8040505@cisco.com> <tslis2lurgb.fsf@cz.mit.edu>
Date: Sun, 17 Apr 2005 13:32:11 -0700
In-Reply-To: <tslis2lurgb.fsf@cz.mit.edu> (Sam Hartman's message of "Sun, 17
	Apr 2005 15:35:32 -0400")
Message-ID: <sdd5stw3ec.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:

Sam> Also, note that SASL has its own mechanism for conveying the
Sam> inner identity.  So if you were using SASL you might want to
Sam> decide that you didn't need an identity in the SNMP PDU.

[FYI, this (and the other examples) are exactly why the SBSM running
message has a numeric session identifier rather than a user string in
it...  The user string is pulled from the authentication exchange and
is stored by both sides and referenced via the session identifier.
I'd expect TLS, SSH, or anything else that did the authentication
elsewhere to do something similar (and yes, a USM user name field in
the USM security model parameters could in theory be warped into a
session identifier as well.  I'd argue heavily against that scheme
using the same security model number even if the packet format was
otherwise the same)]

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 16:39:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNGYJ-0004qw-Rb; Sun, 17 Apr 2005 16:39:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGYH-0004qr-Ka
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 16:39:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20150
	for <isms@ietf.org>; Sun, 17 Apr 2005 16:39:31 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNGix-00088F-Lc
	for isms@ietf.org; Sun, 17 Apr 2005 16:50:35 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id A12A011DA2E; Sun, 17 Apr 2005 13:39:32 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: AW: [Isms] RADIUS is not a trusted third party
Organization: Sparta
References: <D2E490BD3F24C24598C4605E40024D15189129@mchp9gma.mch.sbs.de>
	<tslmzrxurlt.fsf@cz.mit.edu>
Date: Sun, 17 Apr 2005 13:39:31 -0700
In-Reply-To: <tslmzrxurlt.fsf@cz.mit.edu> (Sam Hartman's message of "Sun, 17
	Apr 2005 15:32:14 -0400")
Message-ID: <sdvf6luoho.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Sun, 17 Apr 2005 15:32:14 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:

Sam> Another concern is that if both parties need to know RADIUS is
Sam> being used it probably means that RADIUS is being misused.

Thank you for stating that so clearly, as I think it's a point that
most people miss when they're thinking about Radius and similar
architectures.  I've been trying to argue from the beginning that the
manager doesn't need to know *what* is being used to authenticate its
credentials as it really only complicates matters much of the time.
However, I've failed in expressing that as clearly as the above
statement does.

[MiM issues, of course, need to be dealt with when the agent passes
those credentials onward]

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 16:47:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNGgP-0005gW-35; Sun, 17 Apr 2005 16:47:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGgO-0005gR-77
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 16:47:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20686
	for <isms@ietf.org>; Sun, 17 Apr 2005 16:47:53 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNGr3-0000d6-A5
	for isms@ietf.org; Sun, 17 Apr 2005 16:58:58 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 9F10211DA2E; Sun, 17 Apr 2005 13:47:53 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Kaushik Narayan <kaushik@cisco.com>
Subject: Re: [Isms] USM Protection vs Transport Protection
Organization: Sparta
References: <6.2.0.14.0.20050415144424.049690b0@mira-sjc5-a.cisco.com>
Date: Sun, 17 Apr 2005 13:47:53 -0700
In-Reply-To: <6.2.0.14.0.20050415144424.049690b0@mira-sjc5-a.cisco.com>
	(Kaushik Narayan's message of "Fri, 15 Apr 2005 14:48:41 -0700")
Message-ID: <sdoecduo3q.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Fri, 15 Apr 2005 14:48:41 -0700, Kaushik Narayan <kaushik@cisco.com> said:

Kaushik> Having gone through the discussion of architectural choices,
Kaushik> I think the first decision that we might want to make is
Kaushik> whether we need continue to use USM for message protection
Kaushik> vs. using some other protection mechanism such as the
Kaushik> transport protection suggested by TLSM.

I very much agree that discussion is needed.  However, I'm not sure
we've "gone through the discussion of architectural choices" yet.  I
think we're at the 95% or so mark yet...  I'm kinda hoping the chairs
will say something soon on their views of where we are.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sun Apr 17 22:13:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNLkH-00025M-Uv; Sun, 17 Apr 2005 22:12:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNLkH-00025F-4D
	for isms@megatron.ietf.org; Sun, 17 Apr 2005 22:12:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12020
	for <isms@ietf.org>; Sun, 17 Apr 2005 22:12:14 -0400 (EDT)
Received: from stratton-two.mit.edu ([18.187.5.2]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNLuz-0007iW-51
	for isms@ietf.org; Sun, 17 Apr 2005 22:23:22 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 3B54DE0063; Sun, 17 Apr 2005 22:12:10 -0400 (EDT)
To: Tschofenig Hannes <hannes.tschofenig@siemens.com>
Subject: Re: [Isms] TLS Inner Application Extension
References: <D2E490BD3F24C24598C4605E40024D15189128@mchp9gma.mch.sbs.de>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Sun, 17 Apr 2005 22:12:10 -0400
In-Reply-To: <D2E490BD3F24C24598C4605E40024D15189128@mchp9gma.mch.sbs.de>
	(Tschofenig Hannes's message of "Sun, 17 Apr 2005 12:39:29 +0200")
Message-ID: <tslfyxobzph.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Tschofenig" == Tschofenig Hannes <hannes.tschofenig@siemens.com> writes:

    Tschofenig> hi all, may i draw your attention to the following
    Tschofenig> document that might be relevant for your work:
    Tschofenig> http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extensi
    Tschofenig> on-01.txt

    Tschofenig> as a short summary: it integrates the extensible
    Tschofenig> authentication protocol (eap) into the tls handshake.

    Tschofenig> i personally think that this provides much better
    Tschofenig> properties than the proposal of carrying sasl over tls
    Tschofenig> (as proposed in <draft-schoenw-snmp-tlsm-01.txt>).

Note that I'm likely to have the same EAP applicability concerns about
this document as I did about the original EUSM proposal.  Clearly if
scoped within eap-tls or something like that this would be a
reasonable proposal, but I do not thing it is reasonable as a solution
for all cases where TLS is applicable.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 03:43:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNQv8-00054r-Kt; Mon, 18 Apr 2005 03:43:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNQv5-00054m-VU
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 03:43:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23443
	for <isms@ietf.org>; Mon, 18 Apr 2005 03:43:46 -0400 (EDT)
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNR5q-00019y-GL
	for isms@ietf.org; Mon, 18 Apr 2005 03:54:55 -0400
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j3I7hdr2024816;
	Mon, 18 Apr 2005 09:43:40 +0200
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3I7hdmh016089;
	Mon, 18 Apr 2005 09:43:39 +0200
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72)
	id <2SQ5L5X4>; Mon, 18 Apr 2005 09:43:39 +0200
Message-ID: <D2E490BD3F24C24598C4605E40024D153DB359@mchp9gma.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>
Subject: AW: [Isms] TLS Inner Application Extension
Date: Mon, 18 Apr 2005 09:41:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

# hi sam, 

# thanks for your reply. 

> >>>>> "Tschofenig" == Tschofenig Hannes 
> <hannes.tschofenig@siemens.com> writes:
> 
>     Tschofenig> hi all, may i draw your attention to the following
>     Tschofenig> document that might be relevant for your work:
>     Tschofenig> 
> http://www.ietf.org/internet-drafts/draft-funk-tls-inner-appli
cation-extensi
    Tschofenig> on-01.txt

    Tschofenig> as a short summary: it integrates the extensible
    Tschofenig> authentication protocol (eap) into the tls handshake.

    Tschofenig> i personally think that this provides much better
    Tschofenig> properties than the proposal of carrying sasl over tls
    Tschofenig> (as proposed in <draft-schoenw-snmp-tlsm-01.txt>).

Note that I'm likely to have the same EAP applicability concerns about
this document as I did about the original EUSM proposal.
# although they show some differences...

  Clearly if
scoped within eap-tls or something like that this would be a
reasonable proposal, but I do not thing it is reasonable as a solution
for all cases where TLS is applicable.

# i think it is pretty similar to the usage of ikev2. you could use ikev2
(with eap) to establish ipsec sas to secure snmp. this is just at a
different layer. for me it is difficult to understand why people have no
problem with ikev2/ipsec usage (although it is not only used for network
access/vpn) but raise concerns about other protocols that essentially do the
same. 

# btw, what is your impression about using sasl (or the gss-api) on top of
tls? (for example, binding the keys of the two sessions together). if you
actually interact with the aaa infrastructure then you end up having an
eap-aaa alike architecture. 

# ciao
# hannes
 

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 11:07:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNXqe-0007xc-Bx; Mon, 18 Apr 2005 11:07:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNXqc-0007xS-BD
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 11:07:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27402
	for <isms@ietf.org>; Mon, 18 Apr 2005 11:07:36 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNY1Q-0004IF-Cf
	for isms@ietf.org; Mon, 18 Apr 2005 11:18:49 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3IF7AF29643; Mon, 18 Apr 2005 11:07:11 -0400 (EDT)
Received: from nortel.com (wcary0w4.ca.nortel.com [47.129.148.152]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id 29WLS45V; Mon, 18 Apr 2005 11:07:10 -0400
Message-ID: <4263CD1E.8090400@nortel.com>
Date: Mon, 18 Apr 2005 11:07:10 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Marcus Leech <mleech@nortel.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wes Hardaker <hardaker@tislabs.com>
Subject: Re: [Isms] SSH / Reusability / etc
References: <40ql7s$1l3pf5@sj-inbound-c.cisco.com>	<42621328.8040505@cisco.com>
	<tslis2lurgb.fsf@cz.mit.edu> <sdd5stw3ec.fsf@wes.hardakers.net>
In-Reply-To: <sdd5stw3ec.fsf@wes.hardakers.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Unless I'm mis-reading the existing USM spec, the existing username field
  *could* conceivably be "overloaded" with a session identifier 
instead--which
   would be a logical index into a table containing the keys, username, 
etc, etc.

That would be useful in an architectural direction where USM gets touched
  either very little, or not at all, with OOBK.

Wes Hardaker wrote:

>>>>>>On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:
>>>>>>            
>>>>>>
>
>Sam> Also, note that SASL has its own mechanism for conveying the
>Sam> inner identity.  So if you were using SASL you might want to
>Sam> decide that you didn't need an identity in the SNMP PDU.
>
>[FYI, this (and the other examples) are exactly why the SBSM running
>message has a numeric session identifier rather than a user string in
>it...  The user string is pulled from the authentication exchange and
>is stored by both sides and referenced via the session identifier.
>I'd expect TLS, SSH, or anything else that did the authentication
>elsewhere to do something similar (and yes, a USM user name field in
>the USM security model parameters could in theory be warped into a
>session identifier as well.  I'd argue heavily against that scheme
>using the same security model number even if the packet format was
>otherwise the same)]
>
>  
>


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 11:24:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNY6W-0001Bs-02; Mon, 18 Apr 2005 11:24:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNY6T-0001Bi-Mn
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 11:24:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28822
	for <isms@ietf.org>; Mon, 18 Apr 2005 11:23:59 -0400 (EDT)
Message-Id: <200504181523.LAA28822@ietf.org>
Received: from rwcrmhc13.comcast.net ([204.127.198.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNYHG-0005lw-6i
	for isms@ietf.org; Mon, 18 Apr 2005 11:35:13 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc13) with SMTP
	id <2005041815234601500nt1use>; Mon, 18 Apr 2005 15:23:46 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Eliot Lear'" <lear@cisco.com>
Subject: RE: [Isms] SSH / Reusability / etc
Date: Mon, 18 Apr 2005 11:23:40 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVDIOA8wEUF5yqJSSKL5s6r30XFuQBCSQQA
In-Reply-To: <42621328.8040505@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: 'Sam Hartman' <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi Eliot,

I don't think authenticating as eliot and having dave in the PDU is
bad; but dave would need to be independently authenticated. For
example, I don't have a problem authenticating a TLS transport, and
then passing SNMP packets through that transport that would be
SNMP-authenticated (e.g. via USM or RADIUS). Of course, one would need
to be careful of man in the middle attacks.

dbh

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: Sunday, April 17, 2005 3:41 AM
> To: ietfdbh@comcast.net
> Cc: 'Blumenthal, Uri'; 'Sam Hartman'; isms@ietf.org
> Subject: Re: [Isms] SSH / Reusability / etc
> 
> Dave,
> 
> You're exactly correct that OBTW means Oh By The Way.  The 
> substantial 
> surgery that would need to be done is that if you are authenticating

> against the thing you are tunneling into (say, SSH keys with 
> SSH or SASL 
> or TLS with something else like BEEP), I do not think it a 
> good idea to 
> retransmit any additional authentication information in the 
> encapsulated 
> SNMP PDU.  In other words, what would happen if the SSH user 
> authenticates as "eliot" and the PDU contains "dave"?  That
shouldn't 
> happen.
> 
> That's all I'm saying.
> 
> Eliot
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 11:39:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNYLN-0003DV-3J; Mon, 18 Apr 2005 11:39:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYLL-0003DP-Tl
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 11:39:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00010
	for <isms@ietf.org>; Mon, 18 Apr 2005 11:39:21 -0400 (EDT)
Message-Id: <200504181539.LAA00010@ietf.org>
Received: from rwcrmhc12.comcast.net ([216.148.227.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNYWB-0006wu-TK
	for isms@ietf.org; Mon, 18 Apr 2005 11:50:36 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc12) with SMTP
	id <20050418153913014006fv1ae>; Mon, 18 Apr 2005 15:39:14 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: <ietfdbh@comcast.net>, "'Eliot Lear'" <lear@cisco.com>
Subject: RE: [Isms] SSH / Reusability / etc
Date: Mon, 18 Apr 2005 11:39:08 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVDIOA8wEUF5yqJSSKL5s6r30XFuQBCSQQAAACe5KA=
In-Reply-To: <200504181523.LAA28822@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Cc: 'Sam Hartman' <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

As sam points out, if eliot is authorized to proxy for dave, that also
would be acceptable. (I hope I got the wording right).

dbh 

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington
> Sent: Monday, April 18, 2005 11:24 AM
> To: 'Eliot Lear'
> Cc: 'Sam Hartman'; isms@ietf.org
> Subject: RE: [Isms] SSH / Reusability / etc
> 
> Hi Eliot,
> 
> I don't think authenticating as eliot and having dave in the PDU is
> bad; but dave would need to be independently authenticated. For
> example, I don't have a problem authenticating a TLS transport, and
> then passing SNMP packets through that transport that would be
> SNMP-authenticated (e.g. via USM or RADIUS). Of course, one would
need
> to be careful of man in the middle attacks.
> 
> dbh
> 
> > -----Original Message-----
> > From: Eliot Lear [mailto:lear@cisco.com] 
> > Sent: Sunday, April 17, 2005 3:41 AM
> > To: ietfdbh@comcast.net
> > Cc: 'Blumenthal, Uri'; 'Sam Hartman'; isms@ietf.org
> > Subject: Re: [Isms] SSH / Reusability / etc
> > 
> > Dave,
> > 
> > You're exactly correct that OBTW means Oh By The Way.  The 
> > substantial 
> > surgery that would need to be done is that if you are
authenticating
> 
> > against the thing you are tunneling into (say, SSH keys with 
> > SSH or SASL 
> > or TLS with something else like BEEP), I do not think it a 
> > good idea to 
> > retransmit any additional authentication information in the 
> > encapsulated 
> > SNMP PDU.  In other words, what would happen if the SSH user 
> > authenticates as "eliot" and the PDU contains "dave"?  That
> shouldn't 
> > happen.
> > 
> > That's all I'm saying.
> > 
> > Eliot
> > 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 11:57:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNYcw-0004ql-IY; Mon, 18 Apr 2005 11:57:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYcv-0004qd-7h
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 11:57:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01352
	for <isms@ietf.org>; Mon, 18 Apr 2005 11:57:30 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNYnk-00089u-C4
	for isms@ietf.org; Mon, 18 Apr 2005 12:08:45 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-1.cisco.com with ESMTP; 18 Apr 2005 08:57:18 -0700
X-IronPort-AV: i="3.92,110,1112598000"; 
	d="scan'208"; a="629917637:sNHT776120624"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3IFv7Kx010385;
	Mon, 18 Apr 2005 08:57:07 -0700 (PDT)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp473.cisco.com [10.61.65.217])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3IFmHjI012774;
	Mon, 18 Apr 2005 08:48:18 -0700
Message-ID: <4263D8D4.2000705@cisco.com>
Date: Mon, 18 Apr 2005 17:57:08 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietfdbh@comcast.net
Subject: Re: [Isms] SSH / Reusability / etc
References: <40qjfr$1mvcl7@sj-inbound-b.cisco.com>
In-Reply-To: <40qjfr$1mvcl7@sj-inbound-b.cisco.com>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1113839299.273263"; x:"432200"; a:"rsa-sha1"; b:"nofws:1688";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"pZxyeMTgmHBVY9oLyZoANbfBfVk3nivpPSMXdAvhAdH1TJ98uInzM5dGMPEaTvy3bK7Ymrzg"
	"T8UWnhex1k5w13kniGUK2zaXUVzKuHPUI8Uuw1OaMptukYxoKUcNn0tv7RLSOENlXn+DBhvxKDD"
	"l2flFKPjnczIfj2vwTrmQzM4=";
	c:"Date: Mon, 18 Apr 2005 17:57:08 +0200";
	c:"From: Eliot Lear <lear@cisco.com>";
	c:"Subject: Re: [Isms] SSH / Reusability / etc"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: 7bit
Cc: 'Sam Hartman' <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Ok, Dave, but the whole point is to be able to use the authentication 
from the external mechanism...

Thanks,

Eliot

David B Harrington wrote:
> As sam points out, if eliot is authorized to proxy for dave, that also
> would be acceptable. (I hope I got the wording right).
> 
> dbh 
> 
> 
>>-----Original Message-----
>>From: isms-bounces@lists.ietf.org 
>>[mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington
>>Sent: Monday, April 18, 2005 11:24 AM
>>To: 'Eliot Lear'
>>Cc: 'Sam Hartman'; isms@ietf.org
>>Subject: RE: [Isms] SSH / Reusability / etc
>>
>>Hi Eliot,
>>
>>I don't think authenticating as eliot and having dave in the PDU is
>>bad; but dave would need to be independently authenticated. For
>>example, I don't have a problem authenticating a TLS transport, and
>>then passing SNMP packets through that transport that would be
>>SNMP-authenticated (e.g. via USM or RADIUS). Of course, one would
> 
> need
> 
>>to be careful of man in the middle attacks.
>>
>>dbh
>>
>>
>>>-----Original Message-----
>>>From: Eliot Lear [mailto:lear@cisco.com] 
>>>Sent: Sunday, April 17, 2005 3:41 AM
>>>To: ietfdbh@comcast.net
>>>Cc: 'Blumenthal, Uri'; 'Sam Hartman'; isms@ietf.org
>>>Subject: Re: [Isms] SSH / Reusability / etc
>>>
>>>Dave,
>>>
>>>You're exactly correct that OBTW means Oh By The Way.  The 
>>>substantial 
>>>surgery that would need to be done is that if you are
> 
> authenticating
> 
>>>against the thing you are tunneling into (say, SSH keys with 
>>>SSH or SASL 
>>>or TLS with something else like BEEP), I do not think it a 
>>>good idea to 
>>>retransmit any additional authentication information in the 
>>>encapsulated 
>>>SNMP PDU.  In other words, what would happen if the SSH user 
>>>authenticates as "eliot" and the PDU contains "dave"?  That
>>
>>shouldn't 
>>
>>>happen.
>>>
>>>That's all I'm saying.
>>>
>>>Eliot
>>>
>>
>>
>>
>>_______________________________________________
>>Isms mailing list
>>Isms@lists.ietf.org
>>https://www1.ietf.org/mailman/listinfo/isms
>>
> 
> 
> 

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 12:16:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNYva-0000dF-JA; Mon, 18 Apr 2005 12:16:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYvY-0000cx-BH
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 12:16:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02995
	for <isms@ietf.org>; Mon, 18 Apr 2005 12:16:45 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNZ6N-0000z5-NX
	for isms@ietf.org; Mon, 18 Apr 2005 12:28:01 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 1F4C811DA2D; Mon, 18 Apr 2005 09:16:42 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Marcus Leech <mleech@nortel.com>
Subject: Re: [Isms] SSH / Reusability / etc
Organization: Sparta
References: <40ql7s$1l3pf5@sj-inbound-c.cisco.com>
	<42621328.8040505@cisco.com> <tslis2lurgb.fsf@cz.mit.edu>
	<sdd5stw3ec.fsf@wes.hardakers.net> <4263CD1E.8090400@nortel.com>
Date: Mon, 18 Apr 2005 09:16:41 -0700
In-Reply-To: <4263CD1E.8090400@nortel.com> (Marcus Leech's message of "Mon, 18
	Apr 2005 11:07:10 -0400")
Message-ID: <sd3btot5zq.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Mon, 18 Apr 2005 11:07:10 -0400, Marcus Leech <mleech@nortel.com> said:

Marcus> Unless I'm mis-reading the existing USM spec, the existing
Marcus> username field *could* conceivably be "overloaded" with a
Marcus> session identifier instead--which would be a logical index
Marcus> into a table containing the keys, username, etc, etc.

Right, that's pretty much what I said.

Marcus> That would be useful in an architectural direction where USM
Marcus> gets touched either very little, or not at all, with OOBK.

Note that all of the architectures could likely use USM for message
protection if that was the choice (I don't think it's the right
choice, but thats another story).

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:20:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNZvc-0006ph-BQ; Mon, 18 Apr 2005 13:20:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZvb-0006pc-4T
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:20:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07633
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:20:52 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com ([130.76.32.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNa6Q-0005fh-KM
	for isms@ietf.org; Mon, 18 Apr 2005 13:32:08 -0400
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id
	KAA20679 for <isms@ietf.org>; Mon, 18 Apr 2005 10:20:43 -0700 (PDT)
Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id
	j3IHKgm01884
	for <isms@ietf.org>; Mon, 18 Apr 2005 12:20:42 -0500 (CDT)
Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by
	XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:20:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 10:20:35 -0700
Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDDE7@xch-nw-09.nw.nos.boeing.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBHduBt3brlalBRFaIIWnpcPU1UgAExw1QAMJmLQA=
From: "Fleischman, Eric" <eric.fleischman@boeing.com>
To: <isms@ietf.org>
X-OriginalArrivalTime: 18 Apr 2005 17:20:36.0273 (UTC)
	FILETIME=[EF40F210:01C5443A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

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:uri.blumenthal@intel.com]=20
Sent: Thursday, April 14, 2005 1:33 PM
To: j.schoenwaelder@iu-bremen.de; Martin Soukup
Cc: isms@ietf.org
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:j.schoenwaelder@iu-bremen.de]=20
Sent: Thursday, April 14, 2005 12:44 AM
To: Martin Soukup
Cc: Blumenthal, Uri; isms@ietf.org
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=20
instantiate it is IMHO useless.=20

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

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:25:55 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNa0R-0007JB-PP; Mon, 18 Apr 2005 13:25:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNa0Q-0007J6-6n
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:25:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08206
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:25:53 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNaBG-0005qZ-0B
	for isms@ietf.org; Mon, 18 Apr 2005 13:37:07 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3IHPdTb025811; 
	Mon, 18 Apr 2005 17:25:39 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3IHPa0m021110; 
	Mon, 18 Apr 2005 17:25:38 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041810253628821 ; Mon, 18 Apr 2005 10:25:36 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:25:19 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:25:19 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 13:25:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Mon, 18 Apr 2005 13:24:55 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE64F5@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVEKG6cmUpUcapLRpqFe62tcNwejgAEu8Aw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Marcus Leech" <mleech@nortel.com>, "Wes Hardaker" <hardaker@tislabs.com>
X-OriginalArrivalTime: 18 Apr 2005 17:25:17.0525 (UTC)
	FILETIME=[96E49850:01C5443B]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: quoted-printable
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

It is not even an "overload". usmUserName is merely an indeitifier to
bind together the packet with security information in the local table.
As you say, an "index".

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Marcus Leech
Sent: Monday, April 18, 2005 8:07 AM
To: Wes Hardaker
Cc: Sam Hartman; isms@ietf.org
Subject: Re: [Isms] SSH / Reusability / etc

Unless I'm mis-reading the existing USM spec, the existing username
field
  *could* conceivably be "overloaded" with a session identifier=20
instead--which
   would be a logical index into a table containing the keys, username,=20
etc, etc.

That would be useful in an architectural direction where USM gets
touched
  either very little, or not at all, with OOBK.

Wes Hardaker wrote:

>>>>>>On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman
<hartmans-ietf@mit.edu> said:
>>>>>>           =20
>>>>>>
>
>Sam> Also, note that SASL has its own mechanism for conveying the
>Sam> inner identity.  So if you were using SASL you might want to
>Sam> decide that you didn't need an identity in the SNMP PDU.
>
>[FYI, this (and the other examples) are exactly why the SBSM running
>message has a numeric session identifier rather than a user string in
>it...  The user string is pulled from the authentication exchange and
>is stored by both sides and referenced via the session identifier.
>I'd expect TLS, SSH, or anything else that did the authentication
>elsewhere to do something similar (and yes, a USM user name field in
>the USM security model parameters could in theory be warped into a
>session identifier as well.  I'd argue heavily against that scheme
>using the same security model number even if the packet format was
>otherwise the same)]
>
> =20
>


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:34:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNa8f-00006d-Gv; Mon, 18 Apr 2005 13:34:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNa8e-00006Y-6l
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:34:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09213
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:34:23 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com ([130.76.32.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNaJV-0006kg-2z
	for isms@ietf.org; Mon, 18 Apr 2005 13:45:37 -0400
Received: from blv-av-01.boeing.com ([192.42.227.216])
	by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id
	KAA10203; Mon, 18 Apr 2005 10:34:05 -0700 (PDT)
Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id
	j3IHY5N04272; Mon, 18 Apr 2005 10:34:05 -0700 (PDT)
Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by
	XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:34:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 10:34:02 -0700
Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDDE8@xch-nw-09.nw.nos.boeing.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBEukVABWr4QL1TEGtLFNI/vJTIgAHFW6wAML3e0A=
From: "Fleischman, Eric" <eric.fleischman@boeing.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	"Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 18 Apr 2005 17:34:03.0070 (UTC)
	FILETIME=[D02465E0:01C5443C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

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?=20

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=20
>> shares with a RADIUS server...

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

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


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:36:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNaAa-0000MN-Su; Mon, 18 Apr 2005 13:36:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaAa-0000MI-0R
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:36:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09310
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:36:23 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNaLO-0006ur-Vs
	for isms@ietf.org; Mon, 18 Apr 2005 13:47:37 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3IHaCBs032168; 
	Mon, 18 Apr 2005 17:36:12 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3IHa7gh028837; 
	Mon, 18 Apr 2005 17:36:12 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041810361112495 ; Mon, 18 Apr 2005 10:36:11 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:36:11 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:36:11 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 13:36:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 13:35:46 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE6510@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBHduBt3brlalBRFaIIWnpcPU1UgAExw1QAMJmLQAAAJTxkA==
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Fleischman, Eric" <eric.fleischman@boeing.com>, <isms@ietf.org>
X-OriginalArrivalTime: 18 Apr 2005 17:36:09.0467 (UTC)
	FILETIME=[1B7B0CB0:01C5443D]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Fleischman, Eric
Sent: Monday, April 18, 2005 10:21 AM
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

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:uri.blumenthal@intel.com]=20
Sent: Thursday, April 14, 2005 1:33 PM
To: j.schoenwaelder@iu-bremen.de; Martin Soukup
Cc: isms@ietf.org
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:j.schoenwaelder@iu-bremen.de]=20
Sent: Thursday, April 14, 2005 12:44 AM
To: Martin Soukup
Cc: Blumenthal, Uri; isms@ietf.org
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=20
instantiate it is IMHO useless.=20

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

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:37:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNaBb-0000Y9-EM; Mon, 18 Apr 2005 13:37:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaBZ-0000Xu-PO
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:37:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09420
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:37:24 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNaMP-0006w8-QG
	for isms@ietf.org; Mon, 18 Apr 2005 13:48:39 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-1.cisco.com with ESMTP; 18 Apr 2005 10:36:04 -0700
X-IronPort-AV: i="3.92,110,1112598000"; 
	d="scan'208"; a="629967186:sNHT819552860"
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com
	[171.71.163.34])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3IHa02w004648;
	Mon, 18 Apr 2005 10:36:01 -0700 (PDT)
Received: from kaushik-w2k03.cisco.com ([171.69.75.179])
	by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id BAB31959;
	Mon, 18 Apr 2005 10:35:59 -0700 (PDT)
Message-Id: <6.2.0.14.0.20050418103312.04a463a8@mira-sjc5-a.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Mon, 18 Apr 2005 10:35:59 -0700
To: Wes Hardaker <hardaker@tislabs.com>
From: Kaushik Narayan <kaushik@cisco.com>
Subject: Re: [Isms] USM Protection vs Transport Protection
In-Reply-To: <sdoecduo3q.fsf@wes.hardakers.net>
References: <6.2.0.14.0.20050415144424.049690b0@mira-sjc5-a.cisco.com>
	<sdoecduo3q.fsf@wes.hardakers.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi Wes,

Please find my reply inline.

<snipped>



>Kaushik> Having gone through the discussion of architectural choices,
>Kaushik> I think the first decision that we might want to make is
>Kaushik> whether we need continue to use USM for message protection
>Kaushik> vs. using some other protection mechanism such as the
>Kaushik> transport protection suggested by TLSM.
>
>I very much agree that discussion is needed.  However, I'm not sure
>we've "gone through the discussion of architectural choices" yet.  I
>think we're at the 95% or so mark yet...  I'm kinda hoping the chairs
>will say something soon on their views of where we are.


I was actually referring to the fact that we have had a long drawn
out discussion about keying without really any consensus. I still
see folks expressing interest in each of the keying approaches.

We believe that it might be much easier for the WG to move forward
once we can make a decision on the type of protection. for e.g. If we
decide to use transport protection, i.e. choose a transport layer protocol,
such as TLS for SNMPv3 protection then next steps are pretty straight
forward. Alternatively if we choose to use USM (native SNMP security)
for protection of SNMPv3,  then our choices between using in-band or
out-of-band keying and most security protocols can be made to work
either ways.

regards,
   kaushik!



>--
>Wes Hardaker
>Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:38:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNaD5-0000tA-OO; Mon, 18 Apr 2005 13:38:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaD4-0000t5-Ia
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:38:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09570
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:38:57 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNaNv-00070T-Kn
	for isms@ietf.org; Mon, 18 Apr 2005 13:50:12 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 18 Apr 2005 10:38:49 -0700
X-IronPort-AV: i="3.92,110,1112598000"; 
	d="scan'208"; a="251090034:sNHT27947472"
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com
	[171.71.163.34])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3IHci2w008096;
	Mon, 18 Apr 2005 10:38:45 -0700 (PDT)
Received: from kaushik-w2k03.cisco.com ([171.69.75.179])
	by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id BAB32214;
	Mon, 18 Apr 2005 10:38:44 -0700 (PDT)
Message-Id: <6.2.0.14.0.20050418081247.03c09608@mira-sjc5-a.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Mon, 18 Apr 2005 10:38:44 -0700
To: Tschofenig Hannes <hannes.tschofenig@siemens.com>
From: Kaushik Narayan <kaushik@cisco.com>
Subject: Re: AW: [Isms] USM Protection vs Transport Protection
In-Reply-To: <D2E490BD3F24C24598C4605E40024D1518912A@mchp9gma.mch.sbs.de
 >
References: <D2E490BD3F24C24598C4605E40024D1518912A@mchp9gma.mch.sbs.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi Hannes,

It would much easier to decide on the key management part
once we decide on type of protection required, for e.g. if we decide to use
transport protection, i.e. choose a transport layer protocol, such as TLS=
 for
SNMPv3 protection then the key management choice is pretty straight
forward. Alternatively if we choose to use USM (native SNMP security) for
protection of SNMPv3, then our choices between using in-band or out-of-band
keying and most security protocols can be made to work either ways.

regards,
   kaushik!




At 04:23 AM 4/17/2005, Tschofenig Hannes wrote:
>hi kaushik,
>
>it is true that the type of protection has an impact on solution (at least
>with what most protocols provide today).
>however, i think that this issue is the least difficult one. once you have
>the session keys and the algorithms in place it is really easy to protect
>the messages using standard mechanisms.
>
>a more difficult part is to decide on the key management part.
>
>ciao
>hannes
>
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: isms-bounces@lists.ietf.org
> > [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Kaushik Narayan
> > Gesendet: Freitag, 15. April 2005 23:49
> > An: isms@ietf.org
> > Betreff: [Isms] USM Protection vs Transport Protection
> >
> >
> > Hi All,
> >
> > Having gone through the discussion of architectural
> > choices, I think the first decision that we might want
> > to make is whether we need continue to use USM for
> > message protection vs. using some other protection
> > mechanism such as the transport protection suggested
> > by TLSM.
> >
> > regards,
> >    kaushik!
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> >

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:40:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNaEV-0001Rk-7w; Mon, 18 Apr 2005 13:40:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaET-0001Rf-BX
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:40:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09674
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:40:24 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNaPJ-00072O-8A
	for isms@ietf.org; Mon, 18 Apr 2005 13:51:38 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3IHeDYI001236; 
	Mon, 18 Apr 2005 17:40:13 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3IHeDgf004099; 
	Mon, 18 Apr 2005 17:40:13 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041810401313119 ; Mon, 18 Apr 2005 10:40:13 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:40:13 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:40:12 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 13:40:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 13:39:48 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE651D@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVBEukVABWr4QL1TEGtLFNI/vJTIgAHFW6wAML3e0AAAH5ggA==
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Fleischman, Eric" <eric.fleischman@boeing.com>,
	"Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 18 Apr 2005 17:40:11.0090 (UTC)
	FILETIME=[AB7FCB20:01C5443D]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

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

It is OK to create a different design, that awards an SNMP engine with
its own *secure* identity - binding some kind of a key to snmpEngineID
(just RSA/DSA PK pair, SSH key, whatever).=20

This addition will not remove the need to either create a list of
authorized users for each entity, or to define how authorization will be
done online in a reasonable and practical way (or both :-).

-----Original Message-----
From: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20
Sent: Monday, April 18, 2005 10:34 AM
To: Blumenthal, Uri; Sam Hartman
Cc: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

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?=20

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=20
>> shares with a RADIUS server...

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

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


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:53:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNaRI-0002tI-VF; Mon, 18 Apr 2005 13:53:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaRI-0002tB-0O
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:53:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10873
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:53:38 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com ([130.76.32.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNac9-00081p-2B
	for isms@ietf.org; Mon, 18 Apr 2005 14:04:53 -0400
Received: from blv-av-01.boeing.com ([192.42.227.216])
	by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id
	KAA12336; Mon, 18 Apr 2005 10:53:21 -0700 (PDT)
Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id
	j3IHrLN17278; Mon, 18 Apr 2005 10:53:21 -0700 (PDT)
Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by
	XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:53:20 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Mon, 18 Apr 2005 10:53:19 -0700
Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDDE9@xch-nw-09.nw.nos.boeing.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVB+1R8mal7usJYQqWwjTMfK9q1EQAGnVQAAIpWcQA=
From: "Fleischman, Eric" <eric.fleischman@boeing.com>
To: <ietfdbh@comcast.net>, "Wes Hardaker" <hardaker@tislabs.com>,
	"Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 18 Apr 2005 17:53:20.0475 (UTC)
	FILETIME=[820262B0:01C5443F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org


From: David B Harrington [mailto:ietfdbh@comcast.net]=20
>So there is no ambiguity,=20
>
>1) I do not support copying the keys from another=20
>protocol to stuff into USM. I think that approach=20
>creates the potential for exposure of the keys, which=20
>would weaken both protocols.

I trust that you are not objecting re-using an enterprise-wide Kerberos
or PKI authentication system for ISMS?

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 13:59:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNaWw-0003IB-CR; Mon, 18 Apr 2005 13:59:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaWu-0003I6-U7
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 13:59:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11385
	for <isms@ietf.org>; Mon, 18 Apr 2005 13:59:27 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNahk-0008JH-TJ
	for isms@ietf.org; Mon, 18 Apr 2005 14:10:42 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3IHxHvM015913; 
	Mon, 18 Apr 2005 17:59:17 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com
	[132.233.42.129])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3IHx7gn003497; 
	Mon, 18 Apr 2005 17:59:16 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041810591609351 ; Mon, 18 Apr 2005 10:59:16 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:59:07 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 10:59:06 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 13:59:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Mon, 18 Apr 2005 13:58:42 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE6553@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVB+1R8mal7usJYQqWwjTMfK9q1EQAGnVQAAIpWcQAAADD9wA==
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Fleischman, Eric" <eric.fleischman@boeing.com>, <ietfdbh@comcast.net>,
	"Wes Hardaker" <hardaker@tislabs.com>,
	"Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 18 Apr 2005 17:59:05.0163 (UTC)
	FILETIME=[4F7599B0:01C54440]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Copying keys is a bad idea. Using a key exchange protocol to derive keys
for other protocols is OK (examples: Kerberos provides keys for
communicants, EAP provides keys for L2 entities, IKE provides keys for
IPsec). Nothing evil about having something to negotiate keys for either
USM or something else. Nothing evil in that something negotiating its
own keys of course.

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Fleischman, Eric
Sent: Monday, April 18, 2005 10:53 AM
To: ietfdbh@comcast.net; Wes Hardaker; Sam Hartman
Cc: isms@ietf.org
Subject: RE: [Isms] SSH / Reusability / etc


From: David B Harrington [mailto:ietfdbh@comcast.net]=20
>So there is no ambiguity,=20
>
>1) I do not support copying the keys from another=20
>protocol to stuff into USM. I think that approach=20
>creates the potential for exposure of the keys, which=20
>would weaken both protocols.

I trust that you are not objecting re-using an enterprise-wide Kerberos
or PKI authentication system for ISMS?

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 14:13:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNahW-0004gk-Eg; Mon, 18 Apr 2005 14:10:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNahU-0004gA-Uj
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 14:10:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12563
	for <isms@ietf.org>; Mon, 18 Apr 2005 14:10:23 -0400 (EDT)
Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNasL-0000Yf-Eb
	for isms@ietf.org; Mon, 18 Apr 2005 14:21:38 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 4C5BBE0063; Mon, 18 Apr 2005 14:10:16 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FE651D@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Mon, 18 Apr 2005 14:10:14 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FE651D@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Mon, 18 Apr 2005 13:39:48 -0400")
Message-ID: <tsl8y3g552x.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> 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?





_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 14:47:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNbHU-0007vK-Nn; Mon, 18 Apr 2005 14:47:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbHT-0007vF-T8
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 14:47:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16415
	for <isms@ietf.org>; Mon, 18 Apr 2005 14:47:34 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNbSL-0002ZJ-E7
	for isms@ietf.org; Mon, 18 Apr 2005 14:58:49 -0400
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3IIlIJ23322; Mon, 18 Apr 2005 14:47:18 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j3IIlGK14303; Mon, 18 Apr 2005 14:47:16 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RLND7>; Mon, 18 Apr 2005 14:47:16 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B57@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Sam Hartman'" <hartmans-ietf@mit.edu>, "Blumenthal, Uri"
	<uri.blumenthal@intel.com>
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 14:47:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1167960247=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1167960247==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54447.0685F38B"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54447.0685F38B
Content-Type: text/plain

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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Sam Hartman
Sent: Monday, April 18, 2005 2:10 PM
To: Blumenthal, Uri
Cc: isms@ietf.org
Subject: Re: [Isms] Discussion: Architecture direction for ISMS


>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> 
>>>>> 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?





_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C54447.0685F38B
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I don't think that is an accurate restatement. I =
think it would be more accurate to say:</FONT>
</P>

<P><FONT SIZE=3D2>Currently, by design, USM SNMP engines perform =
operations in the context of a user's credentials and do not have =
credentials of their own.</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Sam Hartman</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 18, 2005 2:10 PM</FONT>
<BR><FONT SIZE=3D2>To: Blumenthal, Uri</FONT>
<BR><FONT SIZE=3D2>Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt; &quot;Blumenthal,&quot; =3D=3D =
Blumenthal, Uri &lt;uri.blumenthal@intel.com&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt; writes:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Blumenthal,&gt; I was saying that =
CURRENTLY *by conscious design*</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Blumenthal,&gt; SNMP entities do =
not have credentials of its own, and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Blumenthal,&gt; operate =
exclusively on behalf of users who request</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Blumenthal,&gt; =
operations.</FONT>
</P>

<P><FONT SIZE=3D2>Is the following a technically accurate restatement =
of the above:</FONT>
</P>

<P><FONT SIZE=3D2>Currently, by design, USM SNMP engines share a =
credential for each user?</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Isms mailing list</FONT>
<BR><FONT SIZE=3D2>Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54447.0685F38B--


--===============1167960247==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1167960247==--




From isms-bounces@lists.ietf.org Mon Apr 18 14:50:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNbKP-0000TN-Rq; Mon, 18 Apr 2005 14:50:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbKO-0000TI-KS
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 14:50:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16935
	for <isms@ietf.org>; Mon, 18 Apr 2005 14:50:35 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNbVG-0002fS-0E
	for isms@ietf.org; Mon, 18 Apr 2005 15:01:50 -0400
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3IIoNJ24158; Mon, 18 Apr 2005 14:50:23 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j3IIo6K15012; Mon, 18 Apr 2005 14:50:06 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RLNFZ>; Mon, 18 Apr 2005 14:50:06 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B58@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>, "Fleischman, Eric"
	<eric.fleischman@boeing.com>, isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 14:49:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: c2e58d9873012c90703822e287241385
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0555820523=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0555820523==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54447.1503BE93"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54447.1503BE93
Content-Type: text/plain

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: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Blumenthal, Uri
Sent: Monday, April 18, 2005 1:36 PM
To: Fleischman, Eric; isms@ietf.org
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-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Fleischman, Eric
Sent: Monday, April 18, 2005 10:21 AM
To: isms@ietf.org
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

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:uri.blumenthal@intel.com] 
Sent: Thursday, April 14, 2005 1:33 PM
To: j.schoenwaelder@iu-bremen.de; Martin Soukup
Cc: isms@ietf.org
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:j.schoenwaelder@iu-bremen.de] 
Sent: Thursday, April 14, 2005 12:44 AM
To: Martin Soukup
Cc: Blumenthal, Uri; isms@ietf.org
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

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


------_=_NextPart_001_01C54447.1503BE93
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] Discussion: Architecture direction for ISMS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>What issues with IBK, OOBK, or TK would need to be =
resolved in order for us all to be content with one of them?</FONT>
</P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Blumenthal, Uri</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 18, 2005 1:36 PM</FONT>
<BR><FONT SIZE=3D2>To: Fleischman, Eric; isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>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)?</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: isms-bounces@lists.ietf.org [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>]</FONT>
<BR><FONT SIZE=3D2>On Behalf Of Fleischman, Eric</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 18, 2005 10:21 AM</FONT>
<BR><FONT SIZE=3D2>To: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
</P>

<P><FONT SIZE=3D2>Did the Security ADs give us a rationale for their =
&quot;forbidding&quot; direction? If so, could someone please remind me =
what their rationale was?</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Blumenthal, Uri [<A =
HREF=3D"mailto:uri.blumenthal@intel.com">mailto:uri.blumenthal@intel.com=
</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 14, 2005 1:33 PM</FONT>
<BR><FONT SIZE=3D2>To: j.schoenwaelder@iu-bremen.de; Martin =
Soukup</FONT>
<BR><FONT SIZE=3D2>Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Security ADs forbid us from using either IKE or EAP. =
I'll let Sam speak on this subject.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Juergen Schoenwaelder [<A =
HREF=3D"mailto:j.schoenwaelder@iu-bremen.de">mailto:j.schoenwaelder@iu-b=
remen.de</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 14, 2005 12:44 AM</FONT>
<BR><FONT SIZE=3D2>To: Martin Soukup</FONT>
<BR><FONT SIZE=3D2>Cc: Blumenthal, Uri; isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Isms] Discussion: Architecture =
direction for ISMS</FONT>
</P>

<P><FONT SIZE=3D2>On Wed, Apr 13, 2005 at 09:52:58PM -0400, Martin =
Soukup wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Is there any reason OOBK couldn't use SSH keys, =
or SSH for that</FONT>
<BR><FONT SIZE=3D2>matter. I'm</FONT>
<BR><FONT SIZE=3D2>&gt; not sure the ease of use of a certain existing =
protocol is relevant to</FONT>
<BR><FONT SIZE=3D2>the</FONT>
<BR><FONT SIZE=3D2>&gt; architectural discussion?</FONT>
</P>

<P><FONT SIZE=3D2>An architecture where do not have suitable protocols =
in place to </FONT>
<BR><FONT SIZE=3D2>instantiate it is IMHO useless. </FONT>
</P>

<P><FONT SIZE=3D2>So far, I heard things like IKE and EAP in the =
context of OOBK. I must </FONT>
<BR><FONT SIZE=3D2>have missed the document explaining how to use ssh =
or ssh keys to </FONT>
<BR><FONT SIZE=3D2>establish usm session keys.</FONT>
</P>

<P><FONT SIZE=3D2>/js</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Juergen Schoenwaelder&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
International University Bremen</FONT>
<BR><FONT SIZE=3D2>&lt;<A HREF=3D"http://www.eecs.iu-bremen.de/" =
TARGET=3D"_blank">http://www.eecs.iu-bremen.de/</A>&gt; =
&nbsp;&nbsp;&nbsp; P.O. Box 750 561, 28725 Bremen,</FONT>
<BR><FONT SIZE=3D2>Germany</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Isms mailing list</FONT>
<BR><FONT SIZE=3D2>Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Isms mailing list</FONT>
<BR><FONT SIZE=3D2>Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Isms mailing list</FONT>
<BR><FONT SIZE=3D2>Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54447.1503BE93--


--===============0555820523==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0555820523==--




From isms-bounces@lists.ietf.org Mon Apr 18 15:17:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNbkn-0003jO-6A; Mon, 18 Apr 2005 15:17:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbkl-0003fS-7b
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 15:17:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20483
	for <isms@ietf.org>; Mon, 18 Apr 2005 15:17:48 -0400 (EDT)
Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNbva-0003qd-Sk
	for isms@ietf.org; Mon, 18 Apr 2005 15:29:04 -0400
Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21]
	helo=oemcomputer)
	by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DNbke-0001iY-00
	for isms@ietf.org; Mon, 18 Apr 2005 12:17:44 -0700
Message-ID: <00c201c5444b$887a9ca0$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <3DEC199BD7489643817ECA151F7C5929FE651D@pysmsx401.amr.corp.intel.com>
	<tsl8y3g552x.fsf@cz.mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 12:19:24 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi -

> From: "Sam Hartman" <hartmans-ietf@mit.edu>
> To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
> Cc: <isms@ietf.org>
> Sent: Monday, April 18, 2005 11:10 AM
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
>

> >>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> 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?
...

Key localization and proxy would require a lot of qualifiers on the
restatement before I'd be willing to buy into it.  For example, suppose
Engine A and Engine B are configured so that user X of a command
generator using engine A can do a "get" from a command responder
using Engine B.  As good as that is, it does *NOT* mean that user X
can employ a notification generator using engine B to send information
back to A.  The localized keys to authenticate X at A and X at B are
different, and would be different entries in the usm user table.  That's
why the table has the indexes that it does.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 15:39:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNc5O-0005gl-L6; Mon, 18 Apr 2005 15:39:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNc5M-0005gd-Rw
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 15:39:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22350
	for <isms@ietf.org>; Mon, 18 Apr 2005 15:39:06 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNcGD-0004P1-ER
	for isms@ietf.org; Mon, 18 Apr 2005 15:50:22 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3IJcvsC030107; 
	Mon, 18 Apr 2005 12:38:57 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3IJctVf031575;
	Mon, 18 Apr 2005 12:38:55 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3IJcsZA031569; Mon, 18 Apr 2005 12:38:55 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Mon, 18 Apr 2005 12:38:54 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [Isms] SSH / Reusability / etc
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FE6553@pysmsx401.amr.corp.intel.com>
Message-ID: <Pine.LNX.4.10.10504181237540.22768-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

HI,

I'm not sure that I have heard a proposal that uses "copying
of keys". Is there one?

Regards,
/david t. perkins

On Mon, 18 Apr 2005, Blumenthal, Uri wrote:

> Copying keys is a bad idea. Using a key exchange protocol to derive keys
> for other protocols is OK (examples: Kerberos provides keys for
> communicants, EAP provides keys for L2 entities, IKE provides keys for
> IPsec). Nothing evil about having something to negotiate keys for either
> USM or something else. Nothing evil in that something negotiating its
> own keys of course.
> 
> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
> On Behalf Of Fleischman, Eric
> Sent: Monday, April 18, 2005 10:53 AM
> To: ietfdbh@comcast.net; Wes Hardaker; Sam Hartman
> Cc: isms@ietf.org
> Subject: RE: [Isms] SSH / Reusability / etc
> 
> 
> From: David B Harrington [mailto:ietfdbh@comcast.net] 
> >So there is no ambiguity, 
> >
> >1) I do not support copying the keys from another 
> >protocol to stuff into USM. I think that approach 
> >creates the potential for exposure of the keys, which 
> >would weaken both protocols.
> 
> I trust that you are not objecting re-using an enterprise-wide Kerberos
> or PKI authentication system for ISMS?
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 16:02:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNcRh-0004AC-1X; Mon, 18 Apr 2005 16:02:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcRg-0004A7-4m
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 16:02:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28135
	for <isms@ietf.org>; Mon, 18 Apr 2005 16:02:10 -0400 (EDT)
Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNccX-0006VF-Dv
	for isms@ietf.org; Mon, 18 Apr 2005 16:13:26 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 2B425E0063; Mon, 18 Apr 2005 16:02:02 -0400 (EDT)
To: "Martin Soukup" <msoukup@nortel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B57@zcarhxm2.corp.nortel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Mon, 18 Apr 2005 16:02:02 -0400
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B57@zcarhxm2.corp.nortel.com>
	(Martin Soukup's message of "Mon, 18 Apr 2005 14:47:09 -0400")
Message-ID: <tslsm1n4zwl.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Martin" == Martin Soukup <msoukup@nortel.com> writes:

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

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

    Martin> Martin.

I honestly don't understand how this is different than what I said
except in that it fails to convey that the SNMP engine (or something
associated with it) has a bunch of keys for individual users.  Your
help iin understanding the difference is appreciated.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 17:13:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNdZ8-0007bS-Um; Mon, 18 Apr 2005 17:13:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdZ7-0007ag-K9
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 17:13:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12774
	for <isms@ietf.org>; Mon, 18 Apr 2005 17:13:55 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdjy-0003oT-U4
	for isms@ietf.org; Mon, 18 Apr 2005 17:25:12 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3ILDivM008817; 
	Mon, 18 Apr 2005 21:13:44 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3ILDV0r021753; 
	Mon, 18 Apr 2005 21:13:44 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041814134303391 ; Mon, 18 Apr 2005 14:13:43 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:13:44 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:13:43 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 17:13:41 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 17:13:18 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE67B9@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVEQeh/UI2UW5bmTDW7pz8CgZaBhQAGNaCw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 18 Apr 2005 21:13:41.0928 (UTC)
	FILETIME=[7F5A8A80:01C5445B]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

    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?

IMHO no it is not. Because user credentials kept by one SNMP engine *at
least* cryptographically differ from credentials of the same user on a
different SNMP engine. So there is no sharing.

It is possible though that user credentials for each SNMP engine (for
one user) are generated from one source (user password). In that case
the stored credentials will still be different (grabbing keys from one
engine doesn't open the doors to another), but a way to attack is clear:
brute-force through the password space (the weakest link).






_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 17:20:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNdfI-00083w-DQ; Mon, 18 Apr 2005 17:20:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdfG-00083r-NY
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 17:20:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13597
	for <isms@ietf.org>; Mon, 18 Apr 2005 17:20:16 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdq9-00040b-5N
	for isms@ietf.org; Mon, 18 Apr 2005 17:31:33 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3ILK8Tb002720; 
	Mon, 18 Apr 2005 21:20:08 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com
	[132.233.42.129])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3ILK0Xf026508; 
	Mon, 18 Apr 2005 21:20:08 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041814200830946 ; Mon, 18 Apr 2005 14:20:08 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:20:08 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:20:07 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 17:20:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Isms] Discussion: Architecture direction for ISMS
Date: Mon, 18 Apr 2005 17:19:44 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE67D2@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Discussion: Architecture direction for ISMS
Thread-Index: AcVERxktwj0as95CT2mTOpwcefMdJgAFR/BA
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Martin Soukup" <msoukup@nortel.com>, "Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 18 Apr 2005 21:20:06.0790 (UTC)
	FILETIME=[64BFD260:01C5445C]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0155523071=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0155523071==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5445C.64611E9B"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5445C.64611E9B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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:msoukup@nortel.com]=20
	Sent: Monday, April 18, 2005 11:47 AM
	To: 'Sam Hartman'; Blumenthal, Uri
	Cc: isms@ietf.org
	Subject: RE: [Isms] Discussion: Architecture direction for ISMS
=09
=09

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

	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.=20

	-----Original Message-----=20
	From: isms-bounces@lists.ietf.org
[mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman=20
	Sent: Monday, April 18, 2005 2:10 PM=20
	To: Blumenthal, Uri=20
	Cc: isms@ietf.org=20
	Subject: Re: [Isms] Discussion: Architecture direction for ISMS=20


	>>>>> "Blumenthal," =3D=3D Blumenthal, Uri
<uri.blumenthal@intel.com>=20
	>>>>> writes:=20

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

	Is the following a technically accurate restatement of the
above:=20

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





	_______________________________________________=20
	Isms mailing list=20
	Isms@lists.ietf.org=20
	https://www1.ietf.org/mailman/listinfo/isms=20


------_=_NextPart_001_01C5445C.64611E9B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Isms] Discussion: Architecture direction for =
ISMS</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1492" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D307531821-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Yes,=20
thank you Martin!&nbsp;&nbsp; And "by design" means "there was much =
argument and=20
bickering, and the consensus reached was what you're seeing=20
now".</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Martin Soukup=20
  [mailto:msoukup@nortel.com] <BR><B>Sent:</B> Monday, April 18, 2005 =
11:47=20
  AM<BR><B>To:</B> 'Sam Hartman'; Blumenthal, Uri<BR><B>Cc:</B>=20
  isms@ietf.org<BR><B>Subject:</B> RE: [Isms] Discussion: Architecture =
direction=20
  for ISMS<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT size=3D2>I don't think that is an accurate restatement. I =
think it=20
  would be more accurate to say:</FONT> </P>
  <P><FONT size=3D2>Currently, by design, USM SNMP engines perform =
operations in=20
  the context of a user's credentials and do not have credentials of =
their=20
  own.</FONT></P>
  <P><FONT size=3D2>Martin.</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  isms-bounces@lists.ietf.org [<A=20
  =
href=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.iet=
f.org</A>]=20
  On Behalf Of Sam Hartman</FONT> <BR><FONT size=3D2>Sent: Monday, April =
18, 2005=20
  2:10 PM</FONT> <BR><FONT size=3D2>To: Blumenthal, Uri</FONT> <BR><FONT =

  size=3D2>Cc: isms@ietf.org</FONT> <BR><FONT size=3D2>Subject: Re: =
[Isms]=20
  Discussion: Architecture direction for ISMS</FONT> </P><BR>
  <P><FONT size=3D2>&gt;&gt;&gt;&gt;&gt; "Blumenthal," =3D=3D =
Blumenthal, Uri=20
  &lt;uri.blumenthal@intel.com&gt; </FONT><BR><FONT =
size=3D2>&gt;&gt;&gt;&gt;&gt;=20
  writes:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp; Blumenthal,&gt; I was saying that =
CURRENTLY=20
  *by conscious design*</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
  Blumenthal,&gt; SNMP entities do not have credentials of its own, =
and</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; Blumenthal,&gt; operate =
exclusively on=20
  behalf of users who request</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  Blumenthal,&gt; operations.</FONT> </P>
  <P><FONT size=3D2>Is the following a technically accurate restatement =
of the=20
  above:</FONT> </P>
  <P><FONT size=3D2>Currently, by design, USM SNMP engines share a =
credential for=20
  each user?</FONT> </P><BR><BR><BR><BR>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Isms mailing list</FONT> <BR><FONT=20
  size=3D2>Isms@lists.ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
  target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =

</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5445C.64611E9B--


--===============0155523071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0155523071==--




From isms-bounces@lists.ietf.org Mon Apr 18 17:37:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNdw8-00033k-88; Mon, 18 Apr 2005 17:37:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdw7-00033c-3S
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 17:37:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14951
	for <isms@ietf.org>; Mon, 18 Apr 2005 17:37:40 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNe6z-0004cg-RU
	for isms@ietf.org; Mon, 18 Apr 2005 17:48:58 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3ILbVYI009120; 
	Mon, 18 Apr 2005 21:37:32 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3ILb7Xr022431; 
	Mon, 18 Apr 2005 21:37:31 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041814373105915 ; Mon, 18 Apr 2005 14:37:31 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:37:31 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:37:30 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 17:37:29 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Mon, 18 Apr 2005 17:37:07 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE67F4@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVDjKseK3D7i0UUS5q4d1amTdAOMAAssOCQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Wes Hardaker" <hardaker@tislabs.com>,
	"Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 18 Apr 2005 21:37:29.0577 (UTC)
	FILETIME=[D24C7D90:01C5445E]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

I want one security model to provide session authentication, keying
(derived from authentication), and session parameters (life-time and
mapping to VACM, possibly other parameters). I'd like to have other
security models that intake those parameters and actually protect the
traffic. A-la IPsec approach.

This decoupling allows interchanging keying mechanisms and data
protection mechnisms independently.

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Wes Hardaker
Sent: Sunday, April 17, 2005 1:32 PM
To: Sam Hartman
Cc: isms@ietf.org
Subject: Re: [Isms] SSH / Reusability / etc

>>>>> On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman
<hartmans-ietf@mit.edu> said:

Sam> Also, note that SASL has its own mechanism for conveying the
Sam> inner identity.  So if you were using SASL you might want to
Sam> decide that you didn't need an identity in the SNMP PDU.

[FYI, this (and the other examples) are exactly why the SBSM running
message has a numeric session identifier rather than a user string in
it...  The user string is pulled from the authentication exchange and
is stored by both sides and referenced via the session identifier.
I'd expect TLS, SSH, or anything else that did the authentication
elsewhere to do something similar (and yes, a USM user name field in
the USM security model parameters could in theory be warped into a
session identifier as well.  I'd argue heavily against that scheme
using the same security model number even if the packet format was
otherwise the same)]

--=20
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 17:48:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNe6i-0005ls-7I; Mon, 18 Apr 2005 17:48:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNe6g-0005ln-J8
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 17:48:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15693
	for <isms@ietf.org>; Mon, 18 Apr 2005 17:48:36 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNeHW-00055k-R2
	for isms@ietf.org; Mon, 18 Apr 2005 17:59:54 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3ILmPsC007088; 
	Mon, 18 Apr 2005 14:48:25 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3ILmN6a000385;
	Mon, 18 Apr 2005 14:48:23 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3ILmMr9000381; Mon, 18 Apr 2005 14:48:23 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Mon, 18 Apr 2005 14:48:22 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [Isms] SSH / Reusability / etc
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FE67F4@pysmsx401.amr.corp.intel.com>
Message-ID: <Pine.LNX.4.10.10504181445280.31690-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

HI,

Uri - two is understandable. However, how does that differ from
one security model where the data protection mechanism is
negociated like that which is done in other protocols such
as SSL/TLS?

Regards,
/david t. perkins

On Mon, 18 Apr 2005, Blumenthal, Uri wrote:

> I want one security model to provide session authentication, keying
> (derived from authentication), and session parameters (life-time and
> mapping to VACM, possibly other parameters). I'd like to have other
> security models that intake those parameters and actually protect the
> traffic. A-la IPsec approach.
> 
> This decoupling allows interchanging keying mechanisms and data
> protection mechnisms independently.
> 
> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
> On Behalf Of Wes Hardaker
> Sent: Sunday, April 17, 2005 1:32 PM
> To: Sam Hartman
> Cc: isms@ietf.org
> Subject: Re: [Isms] SSH / Reusability / etc
> 
> >>>>> On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman
> <hartmans-ietf@mit.edu> said:
> 
> Sam> Also, note that SASL has its own mechanism for conveying the
> Sam> inner identity.  So if you were using SASL you might want to
> Sam> decide that you didn't need an identity in the SNMP PDU.
> 
> [FYI, this (and the other examples) are exactly why the SBSM running
> message has a numeric session identifier rather than a user string in
> it...  The user string is pulled from the authentication exchange and
> is stored by both sides and referenced via the session identifier.
> I'd expect TLS, SSH, or anything else that did the authentication
> elsewhere to do something similar (and yes, a USM user name field in
> the USM security model parameters could in theory be warped into a
> session identifier as well.  I'd argue heavily against that scheme
> using the same security model number even if the packet format was
> otherwise the same)]
> 
> -- 
> Wes Hardaker
> Sparta, Inc.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 17:56:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNeDt-0006CM-Qw; Mon, 18 Apr 2005 17:56:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeDs-0006CG-De
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 17:56:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16104
	for <isms@ietf.org>; Mon, 18 Apr 2005 17:56:01 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNeOl-0005QJ-Cd
	for isms@ietf.org; Mon, 18 Apr 2005 18:07:19 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3ILtsTb018281; 
	Mon, 18 Apr 2005 21:55:54 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3ILtroO023154; 
	Mon, 18 Apr 2005 21:55:54 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041814555307890 ; Mon, 18 Apr 2005 14:55:54 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:55:45 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 14:55:45 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Apr 2005 17:55:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Mon, 18 Apr 2005 17:55:20 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE6812@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVEYGV8/zYOULodSWesCqf/DCfgYwAADDOg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "David T. Perkins" <dperkins@dsperkins.com>
X-OriginalArrivalTime: 18 Apr 2005 21:55:43.0818 (UTC)
	FILETIME=[5E846AA0:01C54461]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Sorry, I don't quite understand the question.  AFAIK, TLS is not a key
agreement protocol - it's a data protection protocol that happens to
perform its own keying. Not designed for keying itself. Its use for
keying it tricky because you'd need to bind its credentials with those
negotiated by the "inner" key exchange - and then the question will be
"why not just use TLS itself to protect the data traffic".

I tend to think that GSSAPI is what should be employed (with some minor
modifications like exporting protection info). I'd be killed (or at
least assaulted :-) in 1996 for proposing this, but now I'll probably
get away with my hide intact. :-)

-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com]=20
Sent: Monday, April 18, 2005 2:48 PM
To: Blumenthal, Uri
Cc: Wes Hardaker; Sam Hartman; isms@ietf.org
Subject: RE: [Isms] SSH / Reusability / etc

HI,

Uri - two is understandable. However, how does that differ from
one security model where the data protection mechanism is
negociated like that which is done in other protocols such
as SSL/TLS?

Regards,
/david t. perkins

On Mon, 18 Apr 2005, Blumenthal, Uri wrote:

> I want one security model to provide session authentication, keying
> (derived from authentication), and session parameters (life-time and
> mapping to VACM, possibly other parameters). I'd like to have other
> security models that intake those parameters and actually protect the
> traffic. A-la IPsec approach.
>=20
> This decoupling allows interchanging keying mechanisms and data
> protection mechnisms independently.
>=20
> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
> On Behalf Of Wes Hardaker
> Sent: Sunday, April 17, 2005 1:32 PM
> To: Sam Hartman
> Cc: isms@ietf.org
> Subject: Re: [Isms] SSH / Reusability / etc
>=20
> >>>>> On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman
> <hartmans-ietf@mit.edu> said:
>=20
> Sam> Also, note that SASL has its own mechanism for conveying the
> Sam> inner identity.  So if you were using SASL you might want to
> Sam> decide that you didn't need an identity in the SNMP PDU.
>=20
> [FYI, this (and the other examples) are exactly why the SBSM running
> message has a numeric session identifier rather than a user string in
> it...  The user string is pulled from the authentication exchange and
> is stored by both sides and referenced via the session identifier.
> I'd expect TLS, SSH, or anything else that did the authentication
> elsewhere to do something similar (and yes, a USM user name field in
> the USM security model parameters could in theory be warped into a
> session identifier as well.  I'd argue heavily against that scheme
> using the same security model number even if the packet format was
> otherwise the same)]
>=20
> --=20
> Wes Hardaker
> Sparta, Inc.
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 21:02:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNh8f-0007AN-Si; Mon, 18 Apr 2005 21:02:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNh8e-00078R-BB
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 21:02:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29550
	for <isms@ietf.org>; Mon, 18 Apr 2005 21:02:50 -0400 (EDT)
Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNhJY-0004D2-Aj
	for isms@ietf.org; Mon, 18 Apr 2005 21:14:09 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 1C73BE0064; Mon, 18 Apr 2005 21:02:16 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FE67B9@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Mon, 18 Apr 2005 21:02:15 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FE67B9@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Mon, 18 Apr 2005 17:13:18 -0400")
Message-ID: <tslfyxn4m08.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

    Blumenthal> I was saying that CURRENTLY *by conscious design* SNMP
    Blumenthal> 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?

    Blumenthal,> IMHO no it is not. Because user credentials kept by
    Blumenthal,> one SNMP engine *at least* cryptographically differ
    Blumenthal,> from credentials of the same user on a different SNMP
    Blumenthal,> engine. So there is no sharing.

OK.  I will push the spec up on my reading list.  I'm horribly
confused here.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 21:13:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNhJ2-0000gH-GR; Mon, 18 Apr 2005 21:13:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNhJ1-0000fc-Nf
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 21:13:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00041
	for <isms@ietf.org>; Mon, 18 Apr 2005 21:13:34 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DNhTw-0004Uv-Qz
	for isms@ietf.org; Mon, 18 Apr 2005 21:24:53 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 91CCE11DA2D; Mon, 18 Apr 2005 18:13:29 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
Organization: Sparta
References: <3DEC199BD7489643817ECA151F7C5929FE67B9@pysmsx401.amr.corp.intel.com>
	<tslfyxn4m08.fsf@cz.mit.edu>
Date: Mon, 18 Apr 2005 18:13:28 -0700
In-Reply-To: <tslfyxn4m08.fsf@cz.mit.edu> (Sam Hartman's message of "Mon, 18
	Apr 2005 21:02:15 -0400")
Message-ID: <sdekd736x3.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Mon, 18 Apr 2005 21:02:15 -0400, Sam Hartman <hartmans-ietf@mit.edu> said:

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

Blumenthal,> IMHO no it is not. Because user credentials kept by
Blumenthal,> one SNMP engine *at least* cryptographically differ
Blumenthal,> from credentials of the same user on a different SNMP
Blumenthal,> engine. So there is no sharing.

Sam> OK.  I will push the spec up on my reading list.  I'm horribly
Sam> confused here.

No, you're both right but you're missing what each other is saying (I
think).

    B
   /
  / 
A
 \
  \
   C

In the above 3 engines, A B and C, there may be one USM user name
"Sam" known to all three.  If A is the command generator then the key
that it shares with B for "Sam" (potentially, but not required to be,
derived based on the EngineID) will be different than that it shares
with C (a unique combination of user name and engineID distinctly
identifies a USM user).

Sam's point, I think, is that a credential is actually shared between
A and B and that thus both engines do, at time of communication, have
information about the shared user credential.  B won't respond unless
A has properly proven the credential is shared, and A won't accept a
response from B if the credential is not identical to the request it
sent out (assuming at least authNoPriv here).

Uri's point is that the credential shared for "Sam" between A and B is
different than that for the credential which is shared between A and C
since the credential between A and B is unique to B's engineID (A = CG
here still) and between A and C is unique to C's engineID.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 21:20:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNhPI-0002K0-5y; Mon, 18 Apr 2005 21:20:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNhPG-0002Jt-1T
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 21:20:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00343
	for <isms@ietf.org>; Mon, 18 Apr 2005 21:20:00 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNhaB-0004je-00
	for isms@ietf.org; Mon, 18 Apr 2005 21:31:19 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3J1JlsC024802; 
	Mon, 18 Apr 2005 18:19:47 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3J1JkaR026029;
	Mon, 18 Apr 2005 18:19:46 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3J1Jj9w026024; Mon, 18 Apr 2005 18:19:46 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Mon, 18 Apr 2005 18:19:45 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [Isms] SSH / Reusability / etc
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929FE6812@pysmsx401.amr.corp.intel.com>
Message-ID: <Pine.LNX.4.10.10504181803330.10332-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

HI,

Let me try again.

In your message, you said that you wanted two SNMP security models.
The first to set up a session, and the second to use the parameters
that were set up to exchange SNMP data messages.

And you said that your motivation was to "allow interchanging
keying mechanisms and data protection mechnisms independently."

My question was why could you not have two phases in a single
SNMP security model, since other protocols do so?

However, I was planning on bootstrapping a prototype by
first doing the "running" (your second security model)
assuming a fixed set of parameters, and then adding the
first phase that did the mutual auth, session keying, etc.
So, maybe it might work out to be a little easier.
Note that both the VACM "to group" and the "access"
tables use the security model as an index. Which of
the two security model identifiers were you going
to use?
 
Regards,
/david t. perkins

On Mon, 18 Apr 2005, Blumenthal, Uri wrote:

> Sorry, I don't quite understand the question.  AFAIK, TLS is not a key
> agreement protocol - it's a data protection protocol that happens to
> perform its own keying. Not designed for keying itself. Its use for
> keying it tricky because you'd need to bind its credentials with those
> negotiated by the "inner" key exchange - and then the question will be
> "why not just use TLS itself to protect the data traffic".
> 
> I tend to think that GSSAPI is what should be employed (with some minor
> modifications like exporting protection info). I'd be killed (or at
> least assaulted :-) in 1996 for proposing this, but now I'll probably
> get away with my hide intact. :-)
> 
> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> Sent: Monday, April 18, 2005 2:48 PM
> To: Blumenthal, Uri
> Cc: Wes Hardaker; Sam Hartman; isms@ietf.org
> Subject: RE: [Isms] SSH / Reusability / etc
> 
> HI,
> 
> Uri - two is understandable. However, how does that differ from
> one security model where the data protection mechanism is
> negociated like that which is done in other protocols such
> as SSL/TLS?
> 
> Regards,
> /david t. perkins
> 
> On Mon, 18 Apr 2005, Blumenthal, Uri wrote:
> 
> > I want one security model to provide session authentication, keying
> > (derived from authentication), and session parameters (life-time and
> > mapping to VACM, possibly other parameters). I'd like to have other
> > security models that intake those parameters and actually protect the
> > traffic. A-la IPsec approach.
> > 
> > This decoupling allows interchanging keying mechanisms and data
> > protection mechnisms independently.
> > 
> > -----Original Message-----
> > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
> > On Behalf Of Wes Hardaker
> > Sent: Sunday, April 17, 2005 1:32 PM
> > To: Sam Hartman
> > Cc: isms@ietf.org
> > Subject: Re: [Isms] SSH / Reusability / etc
> > 
> > >>>>> On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman
> > <hartmans-ietf@mit.edu> said:
> > 
> > Sam> Also, note that SASL has its own mechanism for conveying the
> > Sam> inner identity.  So if you were using SASL you might want to
> > Sam> decide that you didn't need an identity in the SNMP PDU.
> > 
> > [FYI, this (and the other examples) are exactly why the SBSM running
> > message has a numeric session identifier rather than a user string in
> > it...  The user string is pulled from the authentication exchange and
> > is stored by both sides and referenced via the session identifier.
> > I'd expect TLS, SSH, or anything else that did the authentication
> > elsewhere to do something similar (and yes, a USM user name field in
> > the USM security model parameters could in theory be warped into a
> > session identifier as well.  I'd argue heavily against that scheme
> > using the same security model number even if the packet format was
> > otherwise the same)]
> > 
> > -- 
> > Wes Hardaker
> > Sparta, Inc.
> > 
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> 
> 


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 18 21:48:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNhqO-0004iS-Go; Mon, 18 Apr 2005 21:48:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNhqN-0004iN-Dl
	for isms@megatron.ietf.org; Mon, 18 Apr 2005 21:48:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02840
	for <isms@ietf.org>; Mon, 18 Apr 2005 21:48:01 -0400 (EDT)
Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNi1H-0005qy-Sn
	for isms@ietf.org; Mon, 18 Apr 2005 21:59:21 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 771ECE0063; Mon, 18 Apr 2005 21:47:58 -0400 (EDT)
To: Wes Hardaker <hardaker@tislabs.com>
Subject: Re: [Isms] Discussion: Architecture direction for ISMS
References: <3DEC199BD7489643817ECA151F7C5929FE67B9@pysmsx401.amr.corp.intel.com>
	<tslfyxn4m08.fsf@cz.mit.edu> <sdekd736x3.fsf@wes.hardakers.net>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Mon, 18 Apr 2005 21:47:57 -0400
In-Reply-To: <sdekd736x3.fsf@wes.hardakers.net> (Wes Hardaker's message of
	"Mon, 18 Apr 2005 18:13:28 -0700")
Message-ID: <tslekd735bm.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Wes" == Wes Hardaker <hardaker@tislabs.com> writes:

    Wes> Sam's point, I think, is that a credential is actually shared
    Wes> between A and B and that thus both engines do, at time of
    Wes> communication, have information about the shared user
    Wes> credential.  B won't respond unless A has properly proven the
    Wes> credential is shared, and A won't accept a response from B if
    Wes> the credential is not identical to the request it sent out
    Wes> (assuming at least authNoPriv here).

Yes, that was my point.

    Wes> Uri's point is that the credential shared for "Sam" between A
    Wes> and B is different than that for the credential which is
    Wes> shared between A and C since the credential between A and B
    Wes> is unique to B's engineID (A = CG here still) and between A
    Wes> and C is unique to C's engineID.


OK, understood.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 19 14:28:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DNxSz-0004ms-Vj; Tue, 19 Apr 2005 14:28:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DNxSy-0004mn-Nn
	for isms@megatron.ietf.org; Tue, 19 Apr 2005 14:28:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05712
	for <isms@ietf.org>; Tue, 19 Apr 2005 14:28:54 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNxe1-0000ke-Lt
	for isms@ietf.org; Tue, 19 Apr 2005 14:40:23 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3JISjoa017512; 
	Tue, 19 Apr 2005 18:28:45 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3JISTQ0024122; 
	Tue, 19 Apr 2005 18:28:45 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005041911284509036 ; Tue, 19 Apr 2005 11:28:45 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 19 Apr 2005 11:28:45 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 19 Apr 2005 11:28:44 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 19 Apr 2005 14:28:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] SSH / Reusability / etc
Date: Tue, 19 Apr 2005 14:28:42 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929FE6D5B@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] SSH / Reusability / etc
Thread-Index: AcVEfetWaW5mUV8eTCelpR7S3J8U7gAhiCfg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "David T. Perkins" <dperkins@dsperkins.com>
X-OriginalArrivalTime: 19 Apr 2005 18:28:43.0748 (UTC)
	FILETIME=[9DFDE240:01C5450D]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> In your message, you said that you wanted two SNMP security models.
> The first to set up a session, and the second to use the parameters
> that were set up to exchange SNMP data messages.

Yes.

> And you said that your motivation was to "allow interchanging
> keying mechanisms and data protection mechnisms independently."

Yes.

> My question was why could you not have two phases in a single
> SNMP security model, since other protocols do so?

To allow one keying model to be able to provide for more than one
data-protecting model.

Also to allow more than one keying model (then I might separate
RADIUS-based keying from SSH-based keying, for example).

Also to simplify data-protecting model(s) - otherwise it will have to
deal with different classes of traffic: establishment traffic and data
traffic. IPsec cleanly separates between the two, and I like it.


> However, I was planning on bootstrapping a prototype by
> first doing the "running" (your second security model)
> assuming a fixed set of parameters, and then adding the
> first phase that did the mutual auth, session keying, etc.

I don't know.

> So, maybe it might work out to be a little easier.
> Note that both the VACM "to group" and the "access"
> tables use the security model as an index. Which of
> the two security model identifiers were you going
> to use?

The second one, of course. The "data-protecting" one. Since VACM is
about the data. RADIUS etc. are about whether a given RADIUS (or SSH)
user is allowed to access this SNMP engine at all.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 19 20:43:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DO3JS-0001xG-RW; Tue, 19 Apr 2005 20:43:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DO3JQ-0001x8-I9
	for isms@megatron.ietf.org; Tue, 19 Apr 2005 20:43:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11581
	for <isms@ietf.org>; Tue, 19 Apr 2005 20:43:25 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO3UX-0006BB-3R
	for isms@ietf.org; Tue, 19 Apr 2005 20:54:57 -0400
Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j3K0hBd06076; Tue, 19 Apr 2005 20:43:11 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	j3K0h9M23584; Tue, 19 Apr 2005 20:43:09 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RM139>; Tue, 19 Apr 2005 20:43:09 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B74@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Alper Yegin'" <alper.yegin@samsung.com>, gwz@cisco.com,
	"'Tschofenig Hannes'" <hannes.tschofenig@siemens.com>, "'Sam Hartman'"
	<hartmans-ietf@mit.edu>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 19 Apr 2005 20:43:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1058891867=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1058891867==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54541.ADCC0527"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54541.ADCC0527
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I definitely look at RADIUS as a trusted third party:

Parties involved:

- authenticating entity (user/application)
- authenticator/policy enforcement point (device)
- authoritative authentication source/policy decision point (RADIUS)

Martin.

> -----Original Message-----
> From: Alper Yegin [mailto:alper.yegin@samsung.com]=20
> Sent: April 19, 2005 8:29 PM
> To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hartman';=20
> Soukup, Martin [CAR:5K50:EXCH]
> Cc: isms@ietf.org; radiusext@ops.ietf.org; eap@frascone.com
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
>=20
>=20
> Glen,
>=20
> > > what is radius for you? (you write that it is not a trusted third
> > > party.)
> >=20
> > It's not.  From the point of view of authentication protocols (PAP, =

> > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":
>=20
> What happens when we look at this picture from the=20
> "authorization" perspective? "Host-to-NAS authorization for=20
> the network access service" is dynamically generated from=20
> "host-to-AAA server" authorization and "AAA server to client=20
> (NAS)" authorization. Wouldn't this constitute a 3-party model?
>=20
> Alper
>=20
>=20
> > the
> > operation of the auth protocols should be exactly the same=20
> as if they=20
> > terminated in the AAA client, instead of elsewhere.  Basically, the =

> > purpose of AAA (again, from the POV of an authentication
> > protocol) is simply scaling.  BTW, a lot of misery has been=20
> caused by=20
> > the erroneous belief that EAP is (or can be) a three-party=20
> > authentication protocol: it isn't, and can't be.  It could=20
> _carry_ a=20
> > three-party protocol (like Kerberos), but EAP in itself is=20
> a two-party=20
> > protocol.
> >=20
> > > why do you care that only one party knows that radius is used? it =

> > > could also be diameter.
> > >
> > > i would like to better understand why some people dislike the aaa =

> > > architecture (radius, diameter).
> >=20
> > I think that the misunderstanding mentioned above might=20
> have something=20
> > to do with it...
> >=20
> > >
> > > ciao
> > > hannes
> > >
> > >
> > >> -----Urspr=FCngliche Nachricht-----
> > >> Von: isms-bounces@lists.ietf.org=20
> > >> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman
> > >> Gesendet: Freitag, 15. April 2005 19:34
> > >> An: Martin Soukup
> > >> Cc: isms@ietf.org
> > >> Betreff: [Isms] RADIUS is not a trusted third party
> > >>
> > >>
> > >>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:
> > >>
> > >>     Martin> RADIUS "Access-Accept" indicates a successful
> > >>     Martin> authenthentication response for a user.
> > >>
> > >>     Martin> The Access-Accept already returns a
> > "Session-Timeout",
> > >>     Martin> defined as "Sets the maximum number of seconds of
> > service
> > >>     Martin> to be provided to the user before the session
> > >>     Martin> terminates. This attribute value becomes the =
per-user
> > >>     Martin> "absolute timeout."".
> > >>
> > >> This only tells the SNMP engine talking to the RADIUS server the =

> > >> timeout.  You need to tell the other side of the exchange the=20
> > >> timeout too.
> > >>
> > >> Remember that RADIUS is a callout service; it is not a trusted
> > third
> > >> party.  In other words, in a particular SNMP authentication, =
only
> > one
> > >> of the parties will know that RADIUS is being used.
> > >>
> > >>
> > >> _______________________________________________
> > >> Isms mailing list
> > >> Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms
> > >>
> > >
> > > _______________________________________________
> > > Isms mailing list
> > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms
> >=20
> > Hope this helps,
> >=20
> > ~gwz
> >=20
> > Why is it that most of the world's problems can't be solved=20
> by simply
> >   listening to John Coltrane? -- Henry Gabriel
> > _______________________________________________
> > eap mailing list
> > eap@frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
>=20
>=20
>=20
>=20

------_=_NextPart_001_01C54541.ADCC0527
Content-Type: text/html;
	charset="ISO-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by
	zcars04f.nortelnetworks.com id j3K0hBd06076
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3DISO-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2658.2=
">
<TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third party</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I definitely look at RADIUS as a trusted third party:</=
FONT>
</P>

<P><FONT SIZE=3D2>Parties involved:</FONT>
</P>

<P><FONT SIZE=3D2>- authenticating entity (user/application)</FONT>
<BR><FONT SIZE=3D2>- authenticator/policy enforcement point (device)</FON=
T>
<BR><FONT SIZE=3D2>- authoritative authentication source/policy decision =
point (RADIUS)</FONT>
</P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Alper Yegin [<A HREF=3D"mailto:alper.yegin@=
samsung.com">mailto:alper.yegin@samsung.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 19, 2005 8:29 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hart=
man'; </FONT>
<BR><FONT SIZE=3D2>&gt; Soukup, Martin [CAR:5K50:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: isms@ietf.org; radiusext@ops.ietf.org; eap@fr=
ascone.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [eap] RE: [Isms] RADIUS is not a tru=
sted third party</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Glen,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; what is radius for you? (you write that=
 it is not a trusted third</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; party.)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; It's not.&nbsp; From the point of view of au=
thentication protocols (PAP, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; CHAP, EAP, etc.), both RADIUS and Diameter a=
re just &quot;wires&quot;:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What happens when we look at this picture from th=
e </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;authorization&quot; perspective? &quot;Host=
-to-NAS authorization for </FONT>
<BR><FONT SIZE=3D2>&gt; the network access service&quot; is dynamically g=
enerated from </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;host-to-AAA server&quot; authorization and =
&quot;AAA server to client </FONT>
<BR><FONT SIZE=3D2>&gt; (NAS)&quot; authorization. Wouldn't this constitu=
te a 3-party model?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Alper</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; operation of the auth protocols should be ex=
actly the same </FONT>
<BR><FONT SIZE=3D2>&gt; as if they </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; terminated in the AAA client, instead of els=
ewhere.&nbsp; Basically, the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; purpose of AAA (again, from the POV of an au=
thentication</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol) is simply scaling.&nbsp; BTW, a lo=
t of misery has been </FONT>
<BR><FONT SIZE=3D2>&gt; caused by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the erroneous belief that EAP is (or can be)=
 a three-party </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; authentication protocol: it isn't, and can't=
 be.&nbsp; It could </FONT>
<BR><FONT SIZE=3D2>&gt; _carry_ a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; three-party protocol (like Kerberos), but EA=
P in itself is </FONT>
<BR><FONT SIZE=3D2>&gt; a two-party </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; why do you care that only one party kno=
ws that radius is used? it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; could also be diameter.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; i would like to better understand why s=
ome people dislike the aaa </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; architecture (radius, diameter).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think that the misunderstanding mentioned =
above might </FONT>
<BR><FONT SIZE=3D2>&gt; have something </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to do with it...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ciao</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; hannes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; -----Urspr=FCngliche Nachricht-----=
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Von: isms-bounces@lists.ietf.org </=
FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; [<A HREF=3D"mailto:isms-bounces@lis=
ts.ietf.org">mailto:isms-bounces@lists.ietf.org</A>] Im Auftrag von Sam H=
artman</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Gesendet: Freitag, 15. April 2005 1=
9:34</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; An: Martin Soukup</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Cc: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Betreff: [Isms] RADIUS is not a tru=
sted third party</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; &quot;Martin&qu=
ot; =3D=3D Martin Soukup &lt;msoukup@nortel.com&gt; writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
RADIUS &quot;Access-Accept&quot; indicates a successful</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
authenthentication response for a user.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
The Access-Accept already returns a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;Session-Timeout&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
defined as &quot;Sets the maximum number of seconds of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; service</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
to be provided to the user before the session</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
terminates. This attribute value becomes the per-user</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
&quot;absolute timeout.&quot;&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; This only tells the SNMP engine tal=
king to the RADIUS server the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; timeout.&nbsp; You need to tell the=
 other side of the exchange the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; timeout too.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Remember that RADIUS is a callout s=
ervice; it is not a trusted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; third</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; party.&nbsp; In other words, in a p=
articular SNMP authentication, only</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; one</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; of the parties will know that RADIU=
S is being used.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; ___________________________________=
____________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Isms@lists.ietf.org <A HREF=3D"http=
s://www1.ietf.org/mailman/listinfo/isms" TARGET=3D"_blank">https://www1.i=
etf.org/mailman/listinfo/isms</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; _______________________________________=
________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Isms@lists.ietf.org <A HREF=3D"https://=
www1.ietf.org/mailman/listinfo/isms" TARGET=3D"_blank">https://www1.ietf.=
org/mailman/listinfo/isms</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hope this helps,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ~gwz</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Why is it that most of the world's problems =
can't be solved </FONT>
<BR><FONT SIZE=3D2>&gt; by simply</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; listening to John Coltrane? -- H=
enry Gabriel</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ____________________________________________=
___</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; eap mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; eap@frascone.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"http://mail.frascone.com/mailman/=
listinfo/eap" TARGET=3D"_blank">http://mail.frascone.com/mailman/listinfo=
/eap</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54541.ADCC0527--


--===============1058891867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1058891867==--




From isms-bounces@lists.ietf.org Tue Apr 19 20:57:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DO3XS-0004QY-26; Tue, 19 Apr 2005 20:57:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DO3XQ-0004OC-26
	for isms@megatron.ietf.org; Tue, 19 Apr 2005 20:57:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12781
	for <isms@ietf.org>; Tue, 19 Apr 2005 20:57:53 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO3iX-0006gP-LL
	for isms@ietf.org; Tue, 19 Apr 2005 21:09:26 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-4.cisco.com with ESMTP; 19 Apr 2005 17:57:47 -0700
Received: from gwzw2k01 (dhcp-128-107-165-105.cisco.com [128.107.165.105])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3K0vhpR011434;
	Tue, 19 Apr 2005 17:57:44 -0700 (PDT)
Message-Id: <200504200057.j3K0vhpR011434@sj-core-4.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Alper Yegin'" <alper.yegin@samsung.com>,
	"'Tschofenig Hannes'" <hannes.tschofenig@siemens.com>,
	"'Sam Hartman'" <hartmans-ietf@mit.edu>,
	"'Martin Soukup'" <msoukup@nortel.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 19 Apr 2005 17:57:42 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <037201c5453f$ef6fe0b0$079da8c0@sisa.samsung.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVFQDWipq6remVqRn2sribJZkhV9wAAud7g
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Alper Yegin <> supposedly scribbled:

> Glen,
>=20
>>> what is radius for you? (you write that it is not a trusted
third
>>> party.)
>>=20
>> It's not.  From the point of view of authentication protocols
(PAP,
>> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":
>=20
> What happens when we look at this picture from the "authorization"
> perspective? "Host-to-NAS authorization for the network access
> service"=20
> is dynamically generated from "host-to-AAA server" authorization
and
> "AAA server to client (NAS)" authorization. Wouldn't this
constitute
> a 3-party model?=20

I'm pretty sure that both Sam & I were just talking about
authentication.  In any case, could you expound a bit?  I don't
actually know what you're talking about.  What do "Host-to-NAS
authorization for the network access service", "host-to-AAA server
authorization" and "AAA server to client (NAS) authorization" mean?
Are you saying that somehow the host authorizes the NAS to provide
it network access?

>=20
> Alper
>=20
>=20
>> the
>> operation of the auth protocols should be exactly the same as if
they
>> terminated in the AAA client, instead of elsewhere.  Basically,
the
>> purpose of AAA (again, from the POV of an authentication
>> protocol) is simply scaling.  BTW, a lot of misery has been
caused by
>> the erroneous belief that EAP is (or can be) a three-party
>> authentication protocol: it isn't, and can't be.  It could
_carry_ a
>> three-party protocol (like Kerberos), but EAP in itself is a
>> two-party protocol.=20
>>=20
>>> why do you care that only one party knows that radius is used?
it
>>> could also be diameter.=20
>>>=20
>>> i would like to better understand why some people dislike the
aaa
>>> architecture (radius, diameter).
>>=20
>> I think that the misunderstanding mentioned above might have
>> something to do with it...=20
>>=20
>>>=20
>>> ciao
>>> hannes
>>>=20
>>>=20
>>>> -----Urspr=FCngliche Nachricht-----
>>>> Von: isms-bounces@lists.ietf.org
>>>> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman
>>>> Gesendet: Freitag, 15. April 2005 19:34
>>>> An: Martin Soukup
>>>> Cc: isms@ietf.org
>>>> Betreff: [Isms] RADIUS is not a trusted third party
>>>>=20
>>>>=20
>>>>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:
>>>>=20
>>>>     Martin> RADIUS "Access-Accept" indicates a successful
>>>>     Martin> authenthentication response for a user.
>>>>=20
>>>>     Martin> The Access-Accept already returns a
"Session-Timeout",
>>>>     Martin> defined as "Sets the maximum number of seconds of
>>>>     service Martin> to be provided to the user before the
session
>>>>     Martin> terminates. This attribute value becomes the
per-user
>>>>     Martin> "absolute timeout."".
>>>>=20
>>>> This only tells the SNMP engine talking to the RADIUS server
the
>>>> timeout.  You need to tell the other side of the exchange the
>>>> timeout too.=20
>>>>=20
>>>> Remember that RADIUS is a callout service; it is not a trusted
>>>> third party.  In other words, in a particular SNMP
authentication,
>>>> only one of the parties will know that RADIUS is being used.
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Isms mailing list
>>>> Isms@lists.ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/isms
>>>>=20
>>>=20
>>> _______________________________________________
>>> Isms mailing list
>>> Isms@lists.ietf.org
>>> https://www1.ietf.org/mailman/listinfo/isms
>>=20
>> Hope this helps,
>>=20
>> ~gwz
>>=20
>> Why is it that most of the world's problems can't be solved by
simply
>>   listening to John Coltrane? -- Henry Gabriel
>> _______________________________________________
>> eap mailing list
>> eap@frascone.com
>> http://mail.frascone.com/mailman/listinfo/eap
>=20
>=20
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 19 21:05:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DO3ee-00055E-QQ; Tue, 19 Apr 2005 21:05:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DO3eb-000559-JG
	for isms@megatron.ietf.org; Tue, 19 Apr 2005 21:05:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13399
	for <isms@ietf.org>; Tue, 19 Apr 2005 21:05:19 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO3pi-0006x9-Sz
	for isms@ietf.org; Tue, 19 Apr 2005 21:16:51 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 19 Apr 2005 18:05:12 -0700
Received: from gwzw2k01 (dhcp-128-107-165-105.cisco.com [128.107.165.105])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3K158b4026188;
	Tue, 19 Apr 2005 18:05:09 -0700 (PDT)
Message-Id: <200504200105.j3K158b4026188@sj-core-3.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Martin Soukup'" <msoukup@nortel.com>,
	"'Alper Yegin'" <alper.yegin@samsung.com>,
	"'Tschofenig Hannes'" <hannes.tschofenig@siemens.com>,
	"'Sam Hartman'" <hartmans-ietf@mit.edu>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 19 Apr 2005 18:05:08 -0700
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B74@zcarhxm2.corp.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVFQf0DNcDTzu21TECheNQntFb3/QAAj+3w
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 509eeaf340e89c687918a6101c6def35
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0456395413=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0456395413==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0105_01C5450A.536B7D30"

This is a multi-part message in MIME format.

------=_NextPart_000_0105_01C5450A.536B7D30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I definitely look at RADIUS as a trusted third party:=20

Parties involved:=20

- authenticating entity (user/application)=20
- authenticator/policy enforcement point (device)=20
- authoritative authentication source/policy decision point (RADIUS)


In order for a "trusted third party" in the technical sense to
exist, the other two parties need to a) know about its existence and
b) trust it.  Does the "authenticating entity" know about the RADIUS
server? =20

Martin.=20

> -----Original Message-----=20
> From: Alper Yegin [mailto:alper.yegin@samsung.com]=20
> Sent: April 19, 2005 8:29 PM=20
> To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hartman';=20
> Soukup, Martin [CAR:5K50:EXCH]=20
> Cc: isms@ietf.org; radiusext@ops.ietf.org; eap@frascone.com=20
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party=20
>=20
>=20
> Glen,=20
>=20
> > > what is radius for you? (you write that it is not a trusted
third=20
> > > party.)=20
> >=20
> > It's not.  From the point of view of authentication protocols
(PAP,=20
> > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":=20
>=20
> What happens when we look at this picture from the=20
> "authorization" perspective? "Host-to-NAS authorization for=20
> the network access service" is dynamically generated from=20
> "host-to-AAA server" authorization and "AAA server to client=20
> (NAS)" authorization. Wouldn't this constitute a 3-party model?=20
>=20
> Alper=20
>=20
>=20
> > the=20
> > operation of the auth protocols should be exactly the same=20
> as if they=20
> > terminated in the AAA client, instead of elsewhere.  Basically,
the=20
> > purpose of AAA (again, from the POV of an authentication=20
> > protocol) is simply scaling.  BTW, a lot of misery has been=20
> caused by=20
> > the erroneous belief that EAP is (or can be) a three-party=20
> > authentication protocol: it isn't, and can't be.  It could=20
> _carry_ a=20
> > three-party protocol (like Kerberos), but EAP in itself is=20
> a two-party=20
> > protocol.=20
> >=20
> > > why do you care that only one party knows that radius is used?
it=20
> > > could also be diameter.=20
> > >=20
> > > i would like to better understand why some people dislike the
aaa=20
> > > architecture (radius, diameter).=20
> >=20
> > I think that the misunderstanding mentioned above might=20
> have something=20
> > to do with it...=20
> >=20
> > >=20
> > > ciao=20
> > > hannes=20
> > >=20
> > >=20
> > >> -----Urspr=FCngliche Nachricht-----=20
> > >> Von: isms-bounces@lists.ietf.org=20
> > >> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam
Hartman=20
> > >> Gesendet: Freitag, 15. April 2005 19:34=20
> > >> An: Martin Soukup=20
> > >> Cc: isms@ietf.org=20
> > >> Betreff: [Isms] RADIUS is not a trusted third party=20
> > >>=20
> > >>=20
> > >>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:=20
> > >>=20
> > >>     Martin> RADIUS "Access-Accept" indicates a successful=20
> > >>     Martin> authenthentication response for a user.=20
> > >>=20
> > >>     Martin> The Access-Accept already returns a=20
> > "Session-Timeout",=20
> > >>     Martin> defined as "Sets the maximum number of seconds of

> > service=20
> > >>     Martin> to be provided to the user before the session=20
> > >>     Martin> terminates. This attribute value becomes the
per-user=20
> > >>     Martin> "absolute timeout."".=20
> > >>=20
> > >> This only tells the SNMP engine talking to the RADIUS server
the=20
> > >> timeout.  You need to tell the other side of the exchange the

> > >> timeout too.=20
> > >>=20
> > >> Remember that RADIUS is a callout service; it is not a
trusted=20
> > third=20
> > >> party.  In other words, in a particular SNMP authentication,
only=20
> > one=20
> > >> of the parties will know that RADIUS is being used.=20
> > >>=20
> > >>=20
> > >> _______________________________________________=20
> > >> Isms mailing list=20
> > >> Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms=20
> > >>=20
> > >=20
> > > _______________________________________________=20
> > > Isms mailing list=20
> > > Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms=20
> >=20
> > Hope this helps,=20
> >=20
> > ~gwz=20
> >=20
> > Why is it that most of the world's problems can't be solved=20
> by simply=20
> >   listening to John Coltrane? -- Henry Gabriel=20
> > _______________________________________________=20
> > eap mailing list=20
> > eap@frascone.com=20
> > http://mail.frascone.com/mailman/listinfo/eap=20
>=20
>=20
>=20
>=20


------=_NextPart_000_0105_01C5450A.536B7D30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third =
party</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DISO-8859-1">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2>I definitely look at RADIUS =
as a trusted=20
third party:</FONT> </DIV>
<P><FONT size=3D2>Parties involved:</FONT> </P>
<P><FONT size=3D2>- authenticating entity (user/application)</FONT> =
<BR><FONT=20
size=3D2>- authenticator/policy enforcement point (device)</FONT> =
<BR><FONT=20
size=3D2>- authoritative authentication source/policy decision point=20
(RADIUS)</FONT>&nbsp;<SPAN class=3D877425900-20042005><FONT face=3DArial =

color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
<P><SPAN class=3D877425900-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>In order=20
for a "trusted third party" in the technical sense to exist, the other =
two=20
parties need to a) know about&nbsp;its existence and b) trust it.&nbsp; =
Does the=20
"authenticating entity"</FONT>&nbsp;<FONT face=3DArial color=3D#0000ff =
size=3D2>know=20
about the RADIUS server?&nbsp; </FONT></SPAN></P>
<P><FONT size=3D2>Martin.</FONT> </P>
<P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
From: Alper Yegin [<A=20
href=3D"mailto:alper.yegin@samsung.com">mailto:alper.yegin@samsung.com</A=
>]=20
</FONT><BR><FONT size=3D2>&gt; Sent: April 19, 2005 8:29 PM</FONT> =
<BR><FONT=20
size=3D2>&gt; To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hartman';=20
</FONT><BR><FONT size=3D2>&gt; Soukup, Martin [CAR:5K50:EXCH]</FONT> =
<BR><FONT=20
size=3D2>&gt; Cc: isms@ietf.org; radiusext@ops.ietf.org; =
eap@frascone.com</FONT>=20
<BR><FONT size=3D2>&gt; Subject: RE: [eap] RE: [Isms] RADIUS is not a =
trusted=20
third party</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Glen,</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
size=3D2>&gt; &gt; &gt; what is radius for you? (you write that it is =
not a=20
trusted third</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; party.)</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; It's not.&nbsp; =
>From the=20
point of view of authentication protocols (PAP, </FONT><BR><FONT =
size=3D2>&gt;=20
&gt; CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":</FONT> =

<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; What happens when =
we look at=20
this picture from the </FONT><BR><FONT size=3D2>&gt; "authorization" =
perspective?=20
"Host-to-NAS authorization for </FONT><BR><FONT size=3D2>&gt; the =
network access=20
service" is dynamically generated from </FONT><BR><FONT size=3D2>&gt; =
"host-to-AAA=20
server" authorization and "AAA server to client </FONT><BR><FONT =
size=3D2>&gt;=20
(NAS)" authorization. Wouldn't this constitute a 3-party model?</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Alper</FONT> <BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
the</FONT>=20
<BR><FONT size=3D2>&gt; &gt; operation of the auth protocols should be =
exactly the=20
same </FONT><BR><FONT size=3D2>&gt; as if they </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
terminated in the AAA client, instead of elsewhere.&nbsp; Basically, the =

</FONT><BR><FONT size=3D2>&gt; &gt; purpose of AAA (again, from the POV =
of an=20
authentication</FONT> <BR><FONT size=3D2>&gt; &gt; protocol) is simply=20
scaling.&nbsp; BTW, a lot of misery has been </FONT><BR><FONT =
size=3D2>&gt; caused=20
by </FONT><BR><FONT size=3D2>&gt; &gt; the erroneous belief that EAP is =
(or can=20
be) a three-party </FONT><BR><FONT size=3D2>&gt; &gt; authentication =
protocol: it=20
isn't, and can't be.&nbsp; It could </FONT><BR><FONT size=3D2>&gt; =
_carry_ a=20
</FONT><BR><FONT size=3D2>&gt; &gt; three-party protocol (like =
Kerberos), but EAP=20
in itself is </FONT><BR><FONT size=3D2>&gt; a two-party </FONT><BR><FONT =

size=3D2>&gt; &gt; protocol.</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
size=3D2>&gt; &gt; &gt; why do you care that only one party knows that =
radius is=20
used? it </FONT><BR><FONT size=3D2>&gt; &gt; &gt; could also be =
diameter.</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt; i would=20
like to better understand why some people dislike the aaa =
</FONT><BR><FONT=20
size=3D2>&gt; &gt; &gt; architecture (radius, diameter).</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; I think that the=20
misunderstanding mentioned above might </FONT><BR><FONT size=3D2>&gt; =
have=20
something </FONT><BR><FONT size=3D2>&gt; &gt; to do with it...</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt; ciao</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
hannes</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt; -----Urspr=FCngliche =
Nachricht-----</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt; Von: isms-bounces@lists.ietf.org=20
</FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; [<A=20
href=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.iet=
f.org</A>]=20
Im Auftrag von Sam Hartman</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
Gesendet:=20
Freitag, 15. April 2005 19:34</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt; An:=20
Martin Soukup</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; Cc:=20
isms@ietf.org</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; Betreff: =
[Isms] RADIUS=20
is not a trusted third party</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
&gt;&gt;&gt;&gt;&gt;&gt;&gt; "Martin" =3D=3D Martin Soukup=20
&lt;msoukup@nortel.com&gt; writes:</FONT> <BR><FONT size=3D2>&gt; &gt;=20
&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
Martin&gt; RADIUS "Access-Accept" indicates a successful</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
authenthentication=20
response for a user.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; The =
Access-Accept=20
already returns a</FONT> <BR><FONT size=3D2>&gt; &gt; =
"Session-Timeout",</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
defined=20
as "Sets the maximum number of seconds of</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
service</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
Martin&gt; to be provided to the user before the session</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
terminates. This=20
attribute value becomes the per-user</FONT> <BR><FONT size=3D2>&gt; &gt; =

&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; "absolute timeout."".</FONT> =

<BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;&gt;=20
This only tells the SNMP engine talking to the RADIUS server the=20
</FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; timeout.&nbsp; You need to =
tell the=20
other side of the exchange the </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
timeout too.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt; Remember that RADIUS is a callout service; =
it is not a=20
trusted</FONT> <BR><FONT size=3D2>&gt; &gt; third</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; &gt;&gt; party.&nbsp; In other words, in a particular SNMP =
authentication,=20
only</FONT> <BR><FONT size=3D2>&gt; &gt; one</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
&gt;&gt; of the parties will know that RADIUS is being used.</FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;&gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; &gt;&gt; Isms mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
Isms@lists.ietf.org <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
<BR><FONT size=3D2>&gt; &gt; &gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; &gt; Isms mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;=20
Isms@lists.ietf.org <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hope this =
helps,</FONT>=20
<BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
~gwz</FONT>=20
<BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Why is =
it that most=20
of the world's problems can't be solved </FONT><BR><FONT size=3D2>&gt; =
by=20
simply</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; listening to John =
Coltrane?=20
-- Henry Gabriel</FONT> <BR><FONT size=3D2>&gt; &gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
&gt; eap mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; =
eap@frascone.com</FONT>=20
<BR><FONT size=3D2>&gt; &gt; <A=20
href=3D"http://mail.frascone.com/mailman/listinfo/eap"=20
target=3D_blank>http://mail.frascone.com/mailman/listinfo/eap</A></FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; </FONT></P></BODY></HTML>

------=_NextPart_000_0105_01C5450A.536B7D30--


--===============0456395413==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0456395413==--




From isms-bounces@lists.ietf.org Wed Apr 20 10:07:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOFrl-0005MC-3W; Wed, 20 Apr 2005 10:07:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DO35p-0000I1-76
	for isms@megatron.ietf.org; Tue, 19 Apr 2005 20:29:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10663
	for <isms@ietf.org>; Tue, 19 Apr 2005 20:29:22 -0400 (EDT)
Received: from mailout2.samsung.com ([203.254.224.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO3Gt-0005p8-UU
	for isms@ietf.org; Tue, 19 Apr 2005 20:40:54 -0400
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	id <0IF700501YONCA@mailout2.samsung.com> for isms@ietf.org; Wed,
	20 Apr 2005 09:29:11 +0900 (KST)
Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	with ESMTP id <0IF700454YONC2@mailout2.samsung.com> for isms@ietf.org;
	Wed, 20 Apr 2005 09:29:11 +0900 (KST)
Received: from Alperyegin ([105.144.29.41])
	by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
	2004))
	with ESMTPA id <0IF700G64YOK9B@mmp1.samsung.com> for isms@ietf.org; Wed,
	20 Apr 2005 09:29:11 +0900 (KST)
Date: Tue, 19 Apr 2005 17:28:52 -0700
From: Alper Yegin <alper.yegin@samsung.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-reply-to: <200504171809.j3HI9spR022495@sj-core-4.cisco.com>
To: gwz@cisco.com, "'Tschofenig Hannes'" <hannes.tschofenig@siemens.com>,
	"'Sam Hartman'" <hartmans-ietf@mit.edu>,
	"'Martin Soukup'" <msoukup@nortel.com>
Message-id: <037201c5453f$ef6fe0b0$079da8c0@sisa.samsung.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 20 Apr 2005 10:07:44 -0400
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Glen,

> > what is radius for you? (you write that it is not a trusted third
> > party.)
>=20
> It's not.  From the point of view of authentication protocols (PAP,
> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":=20

What happens when we look at this picture from the "authorization"
perspective? "Host-to-NAS authorization for the network access service"
is dynamically generated from "host-to-AAA server" authorization and
"AAA server to client (NAS)" authorization. Wouldn't this constitute a
3-party model?

Alper


> the
> operation of the auth protocols should be exactly the same as if
> they terminated in the AAA client, instead of elsewhere.  Basically,
> the purpose of AAA (again, from the POV of an authentication
> protocol) is simply scaling.  BTW, a lot of misery has been caused
> by the erroneous belief that EAP is (or can be) a three-party
> authentication protocol: it isn't, and can't be.  It could _carry_ a
> three-party protocol (like Kerberos), but EAP in itself is a
> two-party protocol.
>=20
> > why do you care that only one party knows that radius is
> > used? it could also be diameter.
> >
> > i would like to better understand why some people dislike the aaa
> > architecture (radius, diameter).
>=20
> I think that the misunderstanding mentioned above might have
> something to do with it...
>=20
> >
> > ciao
> > hannes
> >
> >
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: isms-bounces@lists.ietf.org
> >> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman
> >> Gesendet: Freitag, 15. April 2005 19:34
> >> An: Martin Soukup
> >> Cc: isms@ietf.org
> >> Betreff: [Isms] RADIUS is not a trusted third party
> >>
> >>
> >>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:
> >>
> >>     Martin> RADIUS "Access-Accept" indicates a successful
> >>     Martin> authenthentication response for a user.
> >>
> >>     Martin> The Access-Accept already returns a
> "Session-Timeout",
> >>     Martin> defined as "Sets the maximum number of seconds of
> service
> >>     Martin> to be provided to the user before the session
> >>     Martin> terminates. This attribute value becomes the per-user
> >>     Martin> "absolute timeout."".
> >>
> >> This only tells the SNMP engine talking to the RADIUS server the
> >> timeout.  You need to tell the other side of the exchange the
> >> timeout too.
> >>
> >> Remember that RADIUS is a callout service; it is not a trusted
> third
> >> party.  In other words, in a particular SNMP authentication, only
> one
> >> of the parties will know that RADIUS is being used.
> >>
> >>
> >> _______________________________________________
> >> Isms mailing list
> >> Isms@lists.ietf.org
> >> https://www1.ietf.org/mailman/listinfo/isms
> >>
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
>=20
> Hope this helps,
>=20
> ~gwz
>=20
> Why is it that most of the world's problems can't be solved by
> simply
>   listening to John Coltrane? -- Henry Gabriel
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 20 10:07:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOFrl-0005Ma-AV; Wed, 20 Apr 2005 10:07:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOEFl-0001vo-Vk
	for isms@megatron.ietf.org; Wed, 20 Apr 2005 08:24:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02547
	for <isms@ietf.org>; Wed, 20 Apr 2005 08:24:24 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOEQz-0000dP-0w
	for isms@ietf.org; Wed, 20 Apr 2005 08:36:01 -0400
Received: by zproxy.gmail.com with SMTP id 13so179463nzn
	for <isms@ietf.org>; Wed, 20 Apr 2005 05:24:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=S84G1tWSg1Ta5p9mK+KOdoWMQf0pAzktSc10INcukaT25AUf37fvf6MAzZPgP/NldbziONoXomXPp0pwxdnobFh3LMtn5OKk2nUHXStPs1mJrvTDJ3R1LXU3QrX292OS8PQB6cg6mHwS2rKyky40zhZSJyWe4kv48mf1Bdfj/us=
Received: by 10.36.9.5 with SMTP id 5mr74477nzi;
	Wed, 20 Apr 2005 05:24:15 -0700 (PDT)
Received: by 10.36.67.14 with HTTP; Wed, 20 Apr 2005 05:24:15 -0700 (PDT)
Message-ID: <ba0c4ba805042005247514e043@mail.gmail.com>
Date: Wed, 20 Apr 2005 14:24:15 +0200
From: Jeff Mandin <streetwaves@gmail.com>
To: gwz@cisco.com
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <200504200105.j3K158b4026188@sj-core-3.cisco.com>
Mime-Version: 1.0
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9B74@zcarhxm2.corp.nortel.com>
	<200504200105.j3K158b4026188@sj-core-3.cisco.com>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e
X-Mailman-Approved-At: Wed, 20 Apr 2005 10:07:44 -0400
Cc: Alper Yegin <alper.yegin@samsung.com>, radiusext@ops.ietf.org,
	eap@frascone.com, Sam Hartman <hartmans-ietf@mit.edu>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jmandin@streetwaves-networks.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0755439939=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

--===============0755439939==
Content-Type: multipart/alternative; 
	boundary="----=_Part_917_21961641.1113999855926"

------=_Part_917_21961641.1113999855926
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 4/20/05, Glen Zorn (gwz) <gwz@cisco.com> wrote:
>=20
> I
> In order for a "trusted third party" in the technical sense to exist, the=
=20
> other two parties need to a) know about its existence and b) trust it. Do=
es=20
> the "authenticating entity" know about the RADIUS server?



In an EAP scenario the peer does in fact know about the AAA Server (or=20
rather it always assumes that the AAA might be there). Consequently the=20
AAA-Server does resemble a TTP in the EAP case - as Jesse Walker wrote at=
=20
length in http://mail.frascone.com/pipermail/eap/2004-October/002895.html

There are scenarios (eg. mobile wireless) where the peer is _not at all_=20
interested in the identity of the NAS - but only that the NAS is trusted by=
=20
the larger entity (ie. operator) that uses the AAA-Server for access=20
enforcement. That would amount to an inversion of what seems to be the=20
standard trust model for RADIUS etc.

- Jeff Mandin



> z@cisco.com <gwz@cisco.com>; 'Tschofenig Hannes'; 'Sam Hartman';=20
> > Soukup, Martin [CAR:5K50:EXCH]=20
> > Cc: isms@ietf.org; radiusext@ops.ietf.org; eap@frascone.com=20
> > Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party=20
> >=20
> >=20
> > Glen,=20
> >=20
> > > > what is radius for you? (you write that it is not a trusted third=
=20
> > > > party.)=20
> > >=20
> > > It's not. From the point of view of authentication protocols (PAP,=20
> > > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":=20
> >=20
> > What happens when we look at this picture from the=20
> > "authorization" perspective? "Host-to-NAS authorization for=20
> > the network access service" is dynamically generated from=20
> > "host-to-AAA server" authorization and "AAA server to client=20
> > (NAS)" authorization. Wouldn't this constitute a 3-party model?=20
> >=20
> > Alper=20
> >=20
> >=20
> > > the=20
> > > operation of the auth protocols should be exactly the same=20
> > as if they=20
> > > terminated in the AAA client, instead of elsewhere. Basically, the=20
> > > purpose of AAA (again, from the POV of an authentication=20
> > > protocol) is simply scaling. BTW, a lot of misery has been=20
> > caused by=20
> > > the erroneous belief that EAP is (or can be) a three-party=20
> > > authentication protocol: it isn't, and can't be. It could=20
> > _carry_ a=20
> > > three-party protocol (like Kerberos), but EAP in itself is=20
> > a two-party=20
> > > protocol.=20
> > >=20
> > > > why do you care that only one party knows that radius is used? it=
=20
> > > > could also be diameter.=20
> > > >=20
> > > > i would like to better understand why some people dislike the aaa=
=20
> > > > architecture (radius, diameter).=20
> > >=20
> > > I think that the misunderstanding mentioned above might=20
> > have something=20
> > > to do with it...=20
> > >=20
> > > >=20
> > > > ciao=20
> > > > hannes=20
> > > >=20
> > > >=20
> > > >> -----Urspr=FCngliche Nachricht-----=20
> > > >> Von: isms-bounces@lists.ietf.org=20
> > > >> [mailto:isms-bounces@lists.ietf.org <isms-bounces@lists.ietf.org>]=
=20
> Im Auftrag von Sam Hartman=20
> > > >> Gesendet: Freitag, 15. April 2005 19:34=20
> > > >> An: Martin Soukup=20
> > > >> Cc: isms@ietf.org=20
> > > >> Betreff: [Isms] RADIUS is not a trusted third party=20
> > > >>=20
> > > >>=20
> > > >>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:=20
> > > >>=20
> > > >> Martin> RADIUS "Access-Accept" indicates a successful=20
> > > >> Martin> authenthentication response for a user.=20
> > > >>=20
> > > >> Martin> The Access-Accept already returns a=20
> > > "Session-Timeout",=20
> > > >> Martin> defined as "Sets the maximum number of seconds of=20
> > > service=20
> > > >> Martin> to be provided to the user before the session=20
> > > >> Martin> terminates. This attribute value becomes the per-user=20
> > > >> Martin> "absolute timeout."".=20
> > > >>=20
> > > >> This only tells the SNMP engine talking to the RADIUS server the=
=20
> > > >> timeout. You need to tell the other side of the exchange the=20
> > > >> timeout too.=20
> > > >>=20
> > > >> Remember that RADIUS is a callout service; it is not a trusted=20
> > > third=20
> > > >> party. In other words, in a particular SNMP authentication, only=
=20
> > > one=20
> > > >> of the parties will know that RADIUS is being used.=20
> > > >>=20
> > > >>=20
> > > >> _______________________________________________=20
> > > >> Isms mailing list=20
> > > >> Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms=20
> > > >>=20
> > > >=20
> > > > _______________________________________________=20
> > > > Isms mailing list=20
> > > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms=20
> > >=20
> > > Hope this helps,=20
> > >=20
> > > ~gwz=20
> > >=20
> > > Why is it that most of the world's problems can't be solved=20
> > by simply=20
> > > listening to John Coltrane? -- Henry Gabriel=20
> > > _______________________________________________=20
> > > eap mailing list=20
> > > eap@frascone.com=20
> > > http://mail.frascone.com/mailman/listinfo/eap=20
> >=20
> >=20
> >=20
> >=20
>=20
>

------=_Part_917_21961641.1113999855926
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<br><br><div><span class=3D"gmail_quote">On 4/20/05, <b class=3D"gmail_send=
ername">Glen Zorn (gwz)</b> &lt;<a href=3D"mailto:gwz@cisco.com">gwz@cisco.=
com</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-=
left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left=
: 1ex;">





<div align=3D"left" dir=3D"ltr"><font size=3D"2">I</font></div><span><font =
color=3D"#0000ff" face=3D"Arial" size=3D"2">In order=20
for a &quot;trusted third party&quot; in the technical sense to exist, the =
other two=20
parties need to a) know about&nbsp;its existence and b) trust it.&nbsp; Doe=
s the=20
&quot;authenticating entity&quot;</font>&nbsp;<font color=3D"#0000ff" face=
=3D"Arial" size=3D"2">know=20
about the RADIUS server?</font></span></blockquote><div><br>
<br>
In an EAP scenario the peer does in fact know about the AAA Server (or
rather it always assumes that the AAA might be there).&nbsp;
Consequently the AAA-Server does resemble a TTP in the EAP case&nbsp; -
as Jesse Walker wrote at length in
<a href=3D"http://mail.frascone.com/pipermail/eap/2004-October/002895.html"=
>http://mail.frascone.com/pipermail/eap/2004-October/002895.html</a><br>
</div><br>
There are scenarios (eg. mobile wireless) where the peer is _not at
all_ interested in the identity of the NAS - but only that the NAS is
trusted by the larger entity (ie. operator) that uses the AAA-Server
for access enforcement. &nbsp; That would amount to an inversion of
what seems to be the standard trust model for RADIUS etc.<br>
<br>
- Jeff Mandin<br>
<br>
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<p><span class=3D"q"><font size=3D"2"><a href=3D"mailto:gwz@cisco.com" targ=
et=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,this)">z@ci=
sco.com</a>; 'Tschofenig Hannes'; 'Sam Hartman';=20
</font><br><font size=3D"2">&gt; Soukup, Martin [CAR:5K50:EXCH]</font> <br>=
<font size=3D"2">&gt; Cc: <a href=3D"mailto:isms@ietf.org" target=3D"_blank=
" onclick=3D"return top.js.OpenExtLink(window,event,this)">isms@ietf.org</a=
>; <a href=3D"mailto:radiusext@ops.ietf.org" target=3D"_blank" onclick=3D"r=
eturn top.js.OpenExtLink(window,event,this)">
radiusext@ops.ietf.org</a>; <a href=3D"mailto:eap@frascone.com" target=3D"_=
blank" onclick=3D"return top.js.OpenExtLink(window,event,this)">eap@frascon=
e.com</a></font>=20
<br></span><span class=3D"q"><font size=3D"2">&gt; Subject: RE: [eap] RE: [=
Isms] RADIUS is not a trusted=20
third party</font> <br><font size=3D"2">&gt; </font><br><font size=3D"2">&g=
t;=20
</font><br><font size=3D"2">&gt; Glen,</font> <br><font size=3D"2">&gt; </f=
ont><br><font size=3D"2">&gt; &gt; &gt; what is radius for you? (you write =
that it is not a=20
trusted third</font> <br><font size=3D"2">&gt; &gt; &gt; party.)</font> <br=
><font size=3D"2">&gt; &gt; </font><br><font size=3D"2">&gt; &gt; It's not.=
&nbsp; From the=20
point of view of authentication protocols (PAP, </font><br><font size=3D"2"=
>&gt;=20
&gt; CHAP, EAP, etc.), both RADIUS and Diameter are just &quot;wires&quot;:=
</font>=20
<br><font size=3D"2">&gt; </font><br><font size=3D"2">&gt; What happens whe=
n we look at=20
this picture from the </font><br><font size=3D"2">&gt; &quot;authorization&=
quot; perspective?=20
&quot;Host-to-NAS authorization for </font><br><font size=3D"2">&gt; the ne=
twork access=20
service&quot; is dynamically generated from </font><br><font size=3D"2">&gt=
; &quot;host-to-AAA=20
server&quot; authorization and &quot;AAA server to client </font><br><font =
size=3D"2">&gt;=20
(NAS)&quot; authorization. Wouldn't this constitute a 3-party model?</font>=
 <br><font size=3D"2">&gt; </font><br></span></p><div><span class=3D"e" id=
=3D"q_1035d2440e064dc8_3"><font size=3D"2">&gt; Alper</font> <br><font size=
=3D"2">
&gt;=20
</font><br><font size=3D"2">&gt; </font><br><font size=3D"2">&gt; &gt; the<=
/font>=20
<br><font size=3D"2">&gt; &gt; operation of the auth protocols should be ex=
actly the=20
same </font><br><font size=3D"2">&gt; as if they </font><br><font size=3D"2=
">&gt; &gt;=20
terminated in the AAA client, instead of elsewhere.&nbsp; Basically, the=20
</font><br><font size=3D"2">&gt; &gt; purpose of AAA (again, from the POV o=
f an=20
authentication</font> <br><font size=3D"2">&gt; &gt; protocol) is simply=20
scaling.&nbsp; BTW, a lot of misery has been </font><br><font size=3D"2">&g=
t; caused=20
by </font><br><font size=3D"2">&gt; &gt; the erroneous belief that EAP is (=
or can=20
be) a three-party </font><br><font size=3D"2">&gt; &gt; authentication prot=
ocol: it=20
isn't, and can't be.&nbsp; It could </font><br><font size=3D"2">&gt; _carry=
_ a=20
</font><br><font size=3D"2">&gt; &gt; three-party protocol (like Kerberos),=
 but EAP=20
in itself is </font><br><font size=3D"2">&gt; a two-party </font><br><font =
size=3D"2">&gt; &gt; protocol.</font> <br><font size=3D"2">&gt; &gt; </font=
><br><font size=3D"2">&gt; &gt; &gt; why do you care that only one party kn=
ows that radius is=20
used? it </font><br><font size=3D"2">&gt; &gt; &gt; could also be diameter.=
</font>=20
<br><font size=3D"2">&gt; &gt; &gt;</font> <br><font size=3D"2">&gt; &gt; &=
gt; i would=20
like to better understand why some people dislike the aaa </font><br><font =
size=3D"2">&gt; &gt; &gt; architecture (radius, diameter).</font> <br><font=
 size=3D"2">&gt; &gt; </font><br><font size=3D"2">&gt; &gt; I think that th=
e=20
misunderstanding mentioned above might </font><br><font size=3D"2">&gt; hav=
e=20
something </font><br><font size=3D"2">&gt; &gt; to do with it...</font> <br=
><font size=3D"2">&gt; &gt; </font><br><font size=3D"2">&gt; &gt; &gt;</fon=
t> <br><font size=3D"2">&gt; &gt; &gt; ciao</font> <br><font size=3D"2">&gt=
; &gt; &gt; hannes
</font>=20
<br><font size=3D"2">&gt; &gt; &gt;</font> <br><font size=3D"2">&gt; &gt; &=
gt;</font>=20
<br><font size=3D"2">&gt; &gt; &gt;&gt; -----Urspr=FCngliche Nachricht-----=
</font>=20
<br><font size=3D"2">&gt; &gt; &gt;&gt; Von: <a href=3D"mailto:isms-bounces=
@lists.ietf.org" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(win=
dow,event,this)">isms-bounces@lists.ietf.org</a>=20
</font><br><font size=3D"2">&gt; &gt; &gt;&gt; [<a href=3D"mailto:isms-boun=
ces@lists.ietf.org" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(=
window,event,this)">mailto:isms-bounces@lists.ietf.org</a>]=20
Im Auftrag von Sam Hartman</font> <br><font size=3D"2">&gt; &gt; &gt;&gt; G=
esendet:=20
Freitag, 15. April 2005 19:34</font> <br><font size=3D"2">&gt; &gt; &gt;&gt=
; An:=20
Martin Soukup</font> <br><font size=3D"2">&gt; &gt; &gt;&gt; Cc:=20
<a href=3D"mailto:isms@ietf.org" target=3D"_blank" onclick=3D"return top.js=
.OpenExtLink(window,event,this)">isms@ietf.org</a></font> <br><font size=3D=
"2">&gt; &gt; &gt;&gt; Betreff: [Isms] RADIUS=20
is not a trusted third party</font> <br><font size=3D"2">&gt; &gt; &gt;&gt;=
</font>=20
<br><font size=3D"2">&gt; &gt; &gt;&gt;</font> <br><font size=3D"2">&gt; &g=
t;=20
&gt;&gt;&gt;&gt;&gt;&gt;&gt; &quot;Martin&quot; =3D=3D Martin Soukup=20
&lt;<a href=3D"mailto:msoukup@nortel.com" target=3D"_blank" onclick=3D"retu=
rn top.js.OpenExtLink(window,event,this)">msoukup@nortel.com</a>&gt; writes=
:</font> <br><font size=3D"2">&gt; &gt;=20
&gt;&gt;</font> <br><font size=3D"2">&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
Martin&gt; RADIUS &quot;Access-Accept&quot; indicates a successful</font> <=
br><font size=3D"2">&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; a=
uthenthentication=20
response for a user.</font> <br><font size=3D"2">&gt; &gt; &gt;&gt;</font> =
<br><font size=3D"2">&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
The Access-Accept=20
already returns a</font> <br><font size=3D"2">&gt; &gt; &quot;Session-Timeo=
ut&quot;,</font>=20
<br><font size=3D"2">&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; =
defined=20
as &quot;Sets the maximum number of seconds of</font> <br><font size=3D"2">=
&gt; &gt;=20
service</font> <br><font size=3D"2">&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
Martin&gt; to be provided to the user before the session</font> <br><font s=
ize=3D"2">&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; terminates.=
 This=20
attribute value becomes the per-user</font> <br><font size=3D"2">&gt; &gt;=
=20
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; &quot;absolute timeout.&quot;&q=
uot;.</font>=20
<br><font size=3D"2">&gt; &gt; &gt;&gt;</font> <br><font size=3D"2">&gt; &g=
t; &gt;&gt;=20
This only tells the SNMP engine talking to the RADIUS server the=20
</font><br><font size=3D"2">&gt; &gt; &gt;&gt; timeout.&nbsp; You need to t=
ell the=20
other side of the exchange the </font><br><font size=3D"2">&gt; &gt; &gt;&g=
t;=20
timeout too.</font> <br><font size=3D"2">&gt; &gt; &gt;&gt;</font> <br><fon=
t size=3D"2">&gt; &gt; &gt;&gt; Remember that RADIUS is a callout service; =
it is not a=20
trusted</font> <br><font size=3D"2">&gt; &gt; third</font> <br><font size=
=3D"2">&gt;=20
&gt; &gt;&gt; party.&nbsp; In other words, in a particular SNMP authenticat=
ion,=20
only</font> <br><font size=3D"2">&gt; &gt; one</font> <br><font size=3D"2">=
&gt; &gt;=20
&gt;&gt; of the parties will know that RADIUS is being used.</font> <br><fo=
nt size=3D"2">&gt; &gt; &gt;&gt;</font> <br><font size=3D"2">&gt; &gt; &gt;=
&gt;</font>=20
<br><font size=3D"2">&gt; &gt; &gt;&gt;=20
_______________________________________________</font> <br><font size=3D"2"=
>&gt;=20
&gt; &gt;&gt; Isms mailing list</font> <br><font size=3D"2">&gt; &gt; &gt;&=
gt;=20
<a href=3D"mailto:Isms@lists.ietf.org" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">Isms@lists.ietf.org</a> <a href=3D"h=
ttps://www1.ietf.org/mailman/listinfo/isms" target=3D"_blank" onclick=3D"re=
turn top.js.OpenExtLink(window,event,this)">
https://www1.ietf.org/mailman/listinfo/isms</a></font> <br><font size=3D"2"=
>&gt; &gt; &gt;&gt;</font> <br><font size=3D"2">&gt; &gt; &gt;</font>=20
<br><font size=3D"2">&gt; &gt; &gt;=20
_______________________________________________</font> <br><font size=3D"2"=
>&gt;=20
&gt; &gt; Isms mailing list</font> <br><font size=3D"2">&gt; &gt; &gt;=20
<a href=3D"mailto:Isms@lists.ietf.org" target=3D"_blank" onclick=3D"return =
top.js.OpenExtLink(window,event,this)">Isms@lists.ietf.org</a> <a href=3D"h=
ttps://www1.ietf.org/mailman/listinfo/isms" target=3D"_blank" onclick=3D"re=
turn top.js.OpenExtLink(window,event,this)">
https://www1.ietf.org/mailman/listinfo/isms</a></font> <br><font size=3D"2"=
>&gt; &gt; </font><br><font size=3D"2">&gt; &gt; Hope this helps,</font>=20
<br><font size=3D"2">&gt; &gt; </font><br><font size=3D"2">&gt; &gt; ~gwz</=
font>=20
<br><font size=3D"2">&gt; &gt; </font><br><font size=3D"2">&gt; &gt; Why is=
 it that most=20
of the world's problems can't be solved </font><br><font size=3D"2">&gt; by=
=20
simply</font> <br><font size=3D"2">&gt; &gt;&nbsp;&nbsp; listening to John =
Coltrane?=20
-- Henry Gabriel</font> <br><font size=3D"2">&gt; &gt;=20
_______________________________________________</font> <br><font size=3D"2"=
>&gt;=20
&gt; eap mailing list</font> <br><font size=3D"2">&gt; &gt; <a href=3D"mail=
to:eap@frascone.com" target=3D"_blank" onclick=3D"return top.js.OpenExtLink=
(window,event,this)">eap@frascone.com</a></font>=20
<br><font size=3D"2">&gt; &gt; <a href=3D"http://mail.frascone.com/mailman/=
listinfo/eap" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window=
,event,this)">http://mail.frascone.com/mailman/listinfo/eap</a></font> <br>=
<font size=3D"2">
&gt; </font><br><font size=3D"2">&gt; </font><br><font size=3D"2">&gt;=20
</font><br><font size=3D"2">&gt; </font></span></div><p></p>

</blockquote></div><br>
------=_Part_917_21961641.1113999855926--


--===============0755439939==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0755439939==--




From isms-bounces@lists.ietf.org Wed Apr 20 14:23:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOJrE-0000PF-Ag; Wed, 20 Apr 2005 14:23:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJrA-0000Nu-9b
	for isms@megatron.ietf.org; Wed, 20 Apr 2005 14:23:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05025
	for <isms@ietf.org>; Wed, 20 Apr 2005 14:23:23 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOK2Q-00041t-Rg
	for isms@ietf.org; Wed, 20 Apr 2005 14:35:03 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 20 Apr 2005 11:23:14 -0700
X-IronPort-AV: i="3.92,117,1112598000"; 
	d="scan'208,217"; a="252354462:sNHT63050800"
Received: from gwzw2k01 (dhcp-128-107-165-105.cisco.com [128.107.165.105])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3KIN0L1007721;
	Wed, 20 Apr 2005 11:23:05 -0700 (PDT)
Message-Id: <200504201823.j3KIN0L1007721@sj-core-2.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Jeff Mandin'" <jmandin@streetwaves-networks.com>, <eap@frascone.com>,
	<isms@ietf.org>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 20 Apr 2005 11:23:02 -0700
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <42665A04.2060503@streetwaves-networks.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVFpaYvBy9Ph8iDSzKSt/g0/GxgsQAKw4TQ
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1825501507=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1825501507==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0080_01C5459B.56DF9D70"

This is a multi-part message in MIME format.

------=_NextPart_000_0080_01C5459B.56DF9D70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In order for a "trusted third party" in the technical sense to
exist, the other two parties need to a) know about its existence and
b) trust it.  Does the "authenticating entity" know about the RADIUS
server?
 
In an EAP scenario the peer does in fact know about the AAA Server
(or rather it always assumes that the AAA might be there).   

 
Which EAP are _you_ talking about?  I'm talking about the one
defined in RFC 3748.
 
Consequently the AAA-Server does resemble a TTP in the EAP case  -
as Jesse Walker wrote at length in http://mail.frascone.com
<http://mail.frascone.com/pipermail/eap/2004-October/002895.html>
/pipermail/eap/2004-October/002895.html 
 
To quote from the referenced email (emphasis added): "People have
pointed out before that EAP is a two-party protocol, and that we
can't change the EAP model, and I am sure they will again. However,
the reality is we don't have to change EAP authentication one whit
to address this problem, because it has nothing to do with
authentication; it is about what to do with the results of
authentication and the resulting authorization decision. All we need
is one three-party scheme to deliver keys (properly bound to the
authenticated identities of the NAS and Peer) to the NAS and to the
Peer; we don't want some indeterminate number or 15 or 5 or even 2;
just 1 proper key delivery that will allow applications to meet the
SP 800-56 requirements. Even if EAP is itself two-party, the key
distribution scheme can very well be three-party. And there are
ready-made algorithms we can pick up and use (e.g.,
Needham-Schroeder, Otway-Rees, Bellare-Rogaway) if only we want to.
To reach a solution that will be acceptable to NIST and to the
802.11 community, I beleive we need to define a 3-party protocol
that involves the Peer, the NAS, and the AAA server; we would need
to define how this consumes the EAP keys, and we would have to
define a migration strategy to get from the current practice to the
new mechanism. The document has not done this. I am willing to
create time in my schedule to work with people to remedy this if
there is any will in the group to take on the problem. If we need a
different document to accomplish these ends, then that is ok, too.

I don't see any claims in the above that RADIUS, Diameter or EAP are
three-party protocols, nor that the AAA server is a trusted
third-party; it appears that Jesse might like it to be so, but that
is a different issue.
 
There are scenarios (eg. mobile wireless) where the peer is _not at
all_ interested in the identity of the NAS - but only that the NAS
is trusted by the larger entity (ie. operator) that uses the
AAA-Server for access enforcement.   That would amount to an
inversion of what seems to be the standard trust model for RADIUS
etc.
 
No, that _is the standards trust model for RADIUS, etc. -- or more
precisely, for the access control _system_ which may or may not
include  AAA.  From the user's POV, the system is a black box that
proves it trustworthiness by showing knowledge of a shared secret;
it doesn't matter if the secret is stored in local NVRAM or on a AAA
server 6000 miles away. 


------=_NextPart_000_0080_01C5459B.56DF9D70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
  <DIV>
  <SCRIPT><!--
D(["mb","<span class=3Dq><span><font color=3D\"#0000ff\" =
face=3D\"Arial\" size=3D\"2\">In order \r\nfor a &quot;trusted third =
party&quot; in the technical sense to exist, the other two \r\nparties =
need to a) know about&nbsp;its existence and b) trust it.&nbsp; Does the =
\r\n&quot;authenticating entity&quot;</font>&nbsp;<font =
color=3D\"#0000ff\" face=3D\"Arial\" size=3D\"2\">know \r\nabout the =
RADIUS server?</font></span></span>",1]
);
D(["mb","</blockquote><div><br>\r\n<br>\r\nIn an EAP scenario the peer =
does in fact know about the AAA Server (or\r\nrather it always assumes =
that the AAA might be there).&nbsp;\r\nConsequently the AAA-Server does =
resemble a TTP in the EAP case&nbsp; -\r\nas Jesse Walker wrote at =
length in\r\n<a =
href=3D\"http://mail.frascone.com/pipermail/eap/2004-October/002895.html\=
" target=3D\"_blank\" onclick=3D\"return =
top.js.OpenExtLink(window,event,this)\">http://mail.frascone.com<WBR>/pip=
ermail/eap/2004-October<WBR>/002895.html</a><br>\r\n</div><br>\r\nThere =
are scenarios (eg. mobile wireless) where the peer is _not at\r\nall_ =
interested in the identity of the NAS - but only that the NAS =
is\r\ntrusted by the larger entity (ie. operator) that uses the =
AAA-Server\r\nfor access enforcement. &nbsp; That would amount to an =
inversion of\r\nwhat seems to be the standard trust model for RADIUS =
etc.<br>",1]
);
D(["mb","<span class=3Dsg>\r\n<br>\r\n- Jeff Mandin</span>",1]
);

//--></SCRIPT>
  <SPAN class=3Dq><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>In =
order for a=20
  "trusted third party" in the technical sense to exist, the other two =
parties=20
  need to a) know about&nbsp;its existence and b) trust it.&nbsp; Does =
the=20
  "authenticating entity"</FONT>&nbsp;<FONT face=3DArial color=3D#0000ff =
size=3D2>know=20
  about the RADIUS server?</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3Dq><SPAN></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3Dq><SPAN></SPAN></SPAN>In an EAP scenario the peer =
does in=20
  fact know about the AAA Server (or rather it always assumes that the =
AAA might=20
  be there).&nbsp;&nbsp;<SPAN class=3D958124517-20042005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D958124517-20042005></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D958124517-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Which=20
EAP are _you_ talking about?&nbsp; I'm talking about the one defined in =
RFC=20
3748.</FONT></SPAN></DIV>
<DIV><SPAN class=3D958124517-20042005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV>Consequently the AAA-Server does resemble a TTP in the EAP =
case&nbsp; - as=20
Jesse Walker wrote at length in <A=20
onclick=3D"return top.js.OpenExtLink(window,event,this)"=20
href=3D"http://mail.frascone.com/pipermail/eap/2004-October/002895.html" =

target=3D_blank>http://mail.frascone.com<WBR>/pipermail/eap/2004-October<=
WBR>/002895.html</A><SPAN=20
class=3D958124517-20042005><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D958124517-20042005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D958124517-20042005><FONT face=3DArial><FONT =
color=3D#0000ff=20
size=3D2>To quote from the referenced email (emphasis added): <FONT=20
color=3D#000080>"<STRONG>People have pointed out before that EAP is a =
two-party=20
protocol, and that we can't change the EAP model, and I am sure they =
will again.=20
However, the reality is we don't have to change EAP authentication one =
whit to=20
address this problem, because it has nothing to do with authentication; =
it is=20
about what to do with the results of authentication and the resulting=20
authorization decision.</STRONG> All we need is one three-party scheme =
to=20
deliver keys (properly bound to the authenticated identities of the NAS =
and=20
Peer) to the NAS and to the Peer; we don't want some indeterminate =
number or 15=20
or 5 or even 2; just 1 proper key delivery that will allow applications =
to meet=20
the SP 800-56 requirements. Even if EAP is itself two-party, the key=20
distribution scheme can very well be three-party. And there are =
ready-made=20
algorithms we can pick up and use (e.g., Needham-Schroeder, Otway-Rees,=20
Bellare-Rogaway) if only we want to. </FONT></FONT><FONT color=3D#0000ff =

size=3D2><FONT color=3D#000080>To reach a solution that will be =
acceptable to NIST=20
and to the 802.11 community, I beleive <STRONG>we need to define a =
3-party=20
protocol</STRONG> that involves the Peer, the NAS, and the AAA server; =
we would=20
need to define how this consumes the EAP keys, and we would have to =
define a=20
migration strategy to get from the current practice to the new =
mechanism. The=20
document has not done this. I am willing to create time in my schedule =
to work=20
with people to remedy this if there is any will in the group to take on =
the=20
problem. If we need a different document to accomplish these ends, then =
that is=20
ok, too.</FONT><BR></FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial><SPAN class=3D958124517-20042005><FONT><FONT =
color=3D#0000ff=20
size=3D2>I don't see any claims in the above that&nbsp;RADIUS, Diameter =
or EAP are=20
three-party protocols, nor that the AAA server is a trusted third-party; =
it=20
appears that Jesse might <EM>like</EM> i<EM></EM>t to be so, but that is =

a&nbsp;different issue.<BR></FONT></FONT></SPAN><SPAN=20
class=3D958124517-20042005><FONT color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV>There are scenarios (eg. mobile wireless) where the peer is _not at =
all_=20
interested in the identity of the NAS - but only that the NAS is trusted =
by the=20
larger entity (ie. operator) that uses the AAA-Server for access =
enforcement.=20
&nbsp; That would amount to an inversion of what seems to be the =
standard trust=20
model for RADIUS etc.</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2>No, that =
_is the=20
standards trust model for RADIUS, etc. -- or more precisely, for the =
access=20
control _system_ which may or may not include&nbsp;<SPAN=20
class=3D958124517-20042005>&nbsp;AAA.&nbsp;&nbsp;From the user's POV, =
the system=20
is a black box that proves it trustworthiness by showing knowledge of a =
shared=20
secret; it doesn't matter if the secret is stored in local NVRAM or on a =
AAA=20
server 6000 miles=20
away.&nbsp;</SPAN></FONT></FONT></FONT><BR></DIV></BODY></HTML>

------=_NextPart_000_0080_01C5459B.56DF9D70--


--===============1825501507==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1825501507==--




From isms-bounces@lists.ietf.org Wed Apr 20 21:49:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOQoe-0001Y5-N0; Wed, 20 Apr 2005 21:49:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOQod-0001Y0-5A
	for isms@megatron.ietf.org; Wed, 20 Apr 2005 21:49:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19451
	for <isms@ietf.org>; Wed, 20 Apr 2005 21:49:13 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOQzx-00082M-TV
	for isms@ietf.org; Wed, 20 Apr 2005 22:00:58 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 20 Apr 2005 18:48:55 -0700
X-IronPort-AV: i="3.92,118,1112598000"; 
	d="scan'208,217"; a="252555969:sNHT928376214"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3L1mj32009366;
	Wed, 20 Apr 2005 18:48:50 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 20 Apr 2005 18:48:48 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] YAAP (Yet Another Architecture Proposal) - Localized
	PSKAuth
Date: Wed, 20 Apr 2005 18:48:47 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F882@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] YAAP (Yet Another Architecture Proposal) - Localized
	PSKAuth
Thread-Index: AcVDHeasE+KfYN35Snabdr7n2IZktQC9j90w
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: <j.schoenwaelder@iu-bremen.de>, "Wayne Kading" <wkading@atcorp.com>
X-OriginalArrivalTime: 21 Apr 2005 01:48:48.0110 (UTC)
	FILETIME=[42A188E0:01C54614]
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0865603006=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0865603006==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54614.42478D5F"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C54614.42478D5F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Juergen Schoenwaelder
Sent: Sunday, April 17, 2005 12:19 AM
To: Wayne Kading
Cc: isms@ietf.org
Subject: Re: [Isms] YAAP (Yet Another Architecture Proposal) - Localized
PSKAuth

On Sat, Apr 16, 2005 at 06:43:58PM -0500, Wayne Kading wrote:

> The proposed LPSK architecture has some appealing points.  I'm curious
to
> know how this fits into our architecture evaluation or if any
beneficial
> parts can be used in the existing proposals.  I would be interested in
> hearing some feedback from the WG on the perceived pros/cons of the
LPSK
> proposal.

My understanding is that LPSK is an instantiation of TLSM. BTW, does
someone know here what happened to the SRP SASL? There was an ID called
</draft-burdis-cat-srp-sasl-09.txt> which seems to have disappeared.

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



------_=_NextPart_001_01C54614.42478D5F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT size=3D2><BR><BR>-----Original Message-----<BR>From:=20
isms-bounces@lists.ietf.org [<A=20
href=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.iet=
f.org</A>]=20
On Behalf Of Juergen Schoenwaelder<BR>Sent: Sunday, April 17, 2005 12:19 =

AM<BR>To: Wayne Kading<BR>Cc: isms@ietf.org<BR>Subject: Re: [Isms] YAAP =
(Yet=20
Another Architecture Proposal) - Localized PSKAuth<BR><BR>On Sat, Apr =
16, 2005=20
at 06:43:58PM -0500, Wayne Kading wrote:<BR><BR>&gt; The proposed LPSK=20
architecture has some appealing points.&nbsp; I'm curious to<BR>&gt; =
know how=20
this fits into our architecture evaluation or if any beneficial<BR>&gt; =
parts=20
can be used in the existing proposals.&nbsp; I would be interested =
in<BR>&gt;=20
hearing some feedback from the WG on the perceived pros/cons of the =
LPSK<BR>&gt;=20
proposal.<BR><BR>My understanding is that LPSK is an instantiation of =
TLSM. BTW,=20
does<BR>someone know here what happened to the SRP SASL? There was an ID =

called<BR>&lt;/draft-burdis-cat-srp-sasl-09.txt&gt; which seems to have=20
disappeared.<BR><BR>/js<BR><BR>--<BR>Juergen Schoenwaelder&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
International=20
University Bremen<BR>&lt;<A=20
href=3D"http://www.eecs.iu-bremen.de/">http://www.eecs.iu-bremen.de/</A>&=
gt;=20
&nbsp;&nbsp;&nbsp; P.O. Box 750 561, 28725 Bremen,=20
Germany<BR><BR>_______________________________________________<BR>Isms =
mailing=20
list<BR>Isms@lists.ietf.org<BR><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/isms">https://www1.ietf.or=
g/mailman/listinfo/isms</A><BR></FONT></P></BODY></HTML>

------_=_NextPart_001_01C54614.42478D5F--


--===============0865603006==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0865603006==--




From isms-bounces@lists.ietf.org Wed Apr 20 22:26:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOROa-0005Yk-7a; Wed, 20 Apr 2005 22:26:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOROZ-0005Yf-0w
	for isms@megatron.ietf.org; Wed, 20 Apr 2005 22:26:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21922
	for <isms@ietf.org>; Wed, 20 Apr 2005 22:26:21 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DORZt-0000KO-5g
	for isms@ietf.org; Wed, 20 Apr 2005 22:38:06 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-4.cisco.com with ESMTP; 20 Apr 2005 19:26:10 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3L2PfbI014141;
	Wed, 20 Apr 2005 19:26:07 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 20 Apr 2005 19:25:58 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] YAAP (Yet Another Architecture Proposal) - Localized
	PSKAuth
Date: Wed, 20 Apr 2005 19:25:57 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F884@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] YAAP (Yet Another Architecture Proposal) - Localized
	PSKAuth
Thread-Index: AcVDHeasE+KfYN35Snabdr7n2IZktQC90Z0w
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: <j.schoenwaelder@iu-bremen.de>, "Wayne Kading" <wkading@atcorp.com>
X-OriginalArrivalTime: 21 Apr 2005 02:25:58.0085 (UTC)
	FILETIME=[73CCB750:01C54619]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Juergen Schoenwaelder

On Sat, Apr 16, 2005 at 06:43:58PM -0500, Wayne Kading wrote:
=20
>> The proposed LPSK architecture has some appealing points.  I'm
curious to
>> know how this fits into our architecture evaluation or if any
beneficial
>> parts can be used in the existing proposals.  I would be interested
in
>> hearing some feedback from the WG on the perceived pros/cons of the
LPSK
>> proposal.
>
>My understanding is that LPSK is an instantiation of TLSM.=20

The LPSK proposal has the same motivation with TLSM that encryption
(privacy)=20
and data integrity should be done at transport level.  However
authentication=20
is to be done at SNMP application level, independent w/ transport, and
the=20
Localized PSK method specifically is used for authentication instead of=20
Kerberos, cert, etc.

Khanh

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 10:02:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOcGF-0006U9-VK; Thu, 21 Apr 2005 10:02:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOJoq-0000Fk-7V
	for isms@megatron.ietf.org; Wed, 20 Apr 2005 14:21:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04785
	for <isms@ietf.org>; Wed, 20 Apr 2005 14:20:56 -0400 (EDT)
Received: from mailout1.samsung.com ([203.254.224.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOK03-0003uc-2u
	for isms@ietf.org; Wed, 20 Apr 2005 14:32:36 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	id <0IF900F01CAISK@mailout1.samsung.com> for isms@ietf.org; Thu,
	21 Apr 2005 03:20:42 +0900 (KST)
Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24])
	by mailout1.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	with ESMTP id <0IF9008N1CAIQQ@mailout1.samsung.com> for isms@ietf.org;
	Thu, 21 Apr 2005 03:20:42 +0900 (KST)
Received: from Alperyegin ([105.144.29.41])
	by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built
	Jun 23 2003)) with ESMTPA id <0IF90028WCAFNT@mmp2.samsung.com> for
	isms@ietf.org; Thu, 21 Apr 2005 03:20:42 +0900 (KST)
Date: Wed, 20 Apr 2005 11:20:21 -0700
From: Alper Yegin <alper.yegin@samsung.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-reply-to: <200504200057.j3K0vhpR011434@sj-core-4.cisco.com>
To: gwz@cisco.com, "'Tschofenig Hannes'" <hannes.tschofenig@siemens.com>,
	"'Sam Hartman'" <hartmans-ietf@mit.edu>,
	"'Martin Soukup'" <msoukup@nortel.com>
Message-id: <03ab01c545d5$9f1b8a60$079da8c0@sisa.samsung.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 21 Apr 2005 10:02:31 -0400
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> >>> what is radius for you? (you write that it is not a trusted
> third
> >>> party.)
> >>
> >> It's not.  From the point of view of authentication protocols
> (PAP,
> >> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":
> >
> > What happens when we look at this picture from the "authorization"
> > perspective? "Host-to-NAS authorization for the network access
> > service"
> > is dynamically generated from "host-to-AAA server" authorization
> and
> > "AAA server to client (NAS)" authorization. Wouldn't this
> constitute
> > a 3-party model?
>=20
> I'm pretty sure that both Sam & I were just talking about
> authentication. =20

I understand that.


> In any case, could you expound a bit?  I don't
> actually know what you're talking about.  What do "Host-to-NAS
> authorization for the network access service", "host-to-AAA server
> authorization" and "AAA server to client (NAS) authorization" mean?
> Are you saying that somehow the host authorizes the NAS to provide
> it network access?

The host (or the user on the host) is authorized to access the Internet
by relying on its subscription with an operator that runs the AAA
server. SLAs, credentials are used to encode this relation. [1]

A bunch of NASes are also authorized by the same AAA server to provide
access service to subscribers of that operator. This comes in the form
of roaming agreements (list of NAS identifiers, credentials, etc.) [2]

Now, if host1 wants to access the Internet via NAS1, the required
dynamic authorization (that host1 is allowed to access the Internet, and
NAS1 is allowed to provide this service) can be generated by relying on
[1] and [2].

I guess the AAA protocol that runs between the NAS and AAA server is a
"wire" as you said, but the AAA server is the trusted third party. Does
this make sense?

Alper







>=20
> >
> > Alper
> >
> >
> >> the
> >> operation of the auth protocols should be exactly the same as if
> they
> >> terminated in the AAA client, instead of elsewhere.  Basically,
> the
> >> purpose of AAA (again, from the POV of an authentication
> >> protocol) is simply scaling.  BTW, a lot of misery has been
> caused by
> >> the erroneous belief that EAP is (or can be) a three-party
> >> authentication protocol: it isn't, and can't be.  It could
> _carry_ a
> >> three-party protocol (like Kerberos), but EAP in itself is a
> >> two-party protocol.
> >>
> >>> why do you care that only one party knows that radius is used?
> it
> >>> could also be diameter.
> >>>
> >>> i would like to better understand why some people dislike the
> aaa
> >>> architecture (radius, diameter).
> >>
> >> I think that the misunderstanding mentioned above might have
> >> something to do with it...
> >>
> >>>
> >>> ciao
> >>> hannes
> >>>
> >>>
> >>>> -----Urspr=FCngliche Nachricht-----
> >>>> Von: isms-bounces@lists.ietf.org
> >>>> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman
> >>>> Gesendet: Freitag, 15. April 2005 19:34
> >>>> An: Martin Soukup
> >>>> Cc: isms@ietf.org
> >>>> Betreff: [Isms] RADIUS is not a trusted third party
> >>>>
> >>>>
> >>>>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:
> >>>>
> >>>>     Martin> RADIUS "Access-Accept" indicates a successful
> >>>>     Martin> authenthentication response for a user.
> >>>>
> >>>>     Martin> The Access-Accept already returns a
> "Session-Timeout",
> >>>>     Martin> defined as "Sets the maximum number of seconds of
> >>>>     service Martin> to be provided to the user before the
> session
> >>>>     Martin> terminates. This attribute value becomes the
> per-user
> >>>>     Martin> "absolute timeout."".
> >>>>
> >>>> This only tells the SNMP engine talking to the RADIUS server
> the
> >>>> timeout.  You need to tell the other side of the exchange the
> >>>> timeout too.
> >>>>
> >>>> Remember that RADIUS is a callout service; it is not a trusted
> >>>> third party.  In other words, in a particular SNMP
> authentication,
> >>>> only one of the parties will know that RADIUS is being used.
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Isms mailing list
> >>>> Isms@lists.ietf.org
> >>>> https://www1.ietf.org/mailman/listinfo/isms
> >>>>
> >>>
> >>> _______________________________________________
> >>> Isms mailing list
> >>> Isms@lists.ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/isms
> >>
> >> Hope this helps,
> >>
> >> ~gwz
> >>
> >> Why is it that most of the world's problems can't be solved by
> simply
> >>   listening to John Coltrane? -- Henry Gabriel
> >> _______________________________________________
> >> eap mailing list
> >> eap@frascone.com
> >> http://mail.frascone.com/mailman/listinfo/eap
> >
> >
> > _______________________________________________
> > eap mailing list
> > eap@frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
>=20
> Hope this helps,
>=20
> ~gwz
>=20
> Why is it that most of the world's problems can't be solved by
> simply
>   listening to John Coltrane? -- Henry Gabriel



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 10:03:08 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOcGq-0006Y1-6E; Thu, 21 Apr 2005 10:03:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOcGo-0006XQ-Tf
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 10:03:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01896
	for <isms@ietf.org>; Thu, 21 Apr 2005 10:03:05 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOcSF-0008Rz-5H
	for isms@ietf.org; Thu, 21 Apr 2005 10:14:56 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3LE2lDU007395; 
	Thu, 21 Apr 2005 14:02:47 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3LE2gY6014531; 
	Thu, 21 Apr 2005 14:02:46 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042107024522425 ; Thu, 21 Apr 2005 07:02:45 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 07:02:46 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 07:02:45 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 10:02:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 10:02:00 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290103ED92@pysmsx401.amr.corp.intel.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVFQf0DNcDTzu21TECheNQntFb3/QAAj+3wAE2UDHA=
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <gwz@cisco.com>, "Martin Soukup" <msoukup@nortel.com>,
	"Alper Yegin" <alper.yegin@samsung.com>,
	"Tschofenig Hannes" <hannes.tschofenig@siemens.com>,
	"Sam Hartman" <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 21 Apr 2005 14:02:24.0591 (UTC)
	FILETIME=[BE7F85F0:01C5467A]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0434720099=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0434720099==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5467A.BE0BC077"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5467A.BE0BC077
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Does the "authenticating entity" know about the RADIUS? IMHO yes it does =
because in EAPv2 that's who it runs the EAP method with.


________________________________

	From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] =
On Behalf Of Glen Zorn (gwz)
	Sent: Tuesday, April 19, 2005 9:05 PM
	To: 'Martin Soukup'; 'Alper Yegin'; 'Tschofenig Hannes'; 'Sam Hartman'
	Cc: isms@ietf.org; eap@frascone.com; radiusext@ops.ietf.org
	Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
=09
=09
	I definitely look at RADIUS as a trusted third party:=20

	Parties involved:=20

	- authenticating entity (user/application)=20
	- authenticator/policy enforcement point (device)=20
	- authoritative authentication source/policy decision point (RADIUS) =20

	In order for a "trusted third party" in the technical sense to exist, =
the other two parties need to a) know about its existence and b) trust =
it.  Does the "authenticating entity" know about the RADIUS server? =20

	Martin.=20

	> -----Original Message-----=20
	> From: Alper Yegin [mailto:alper.yegin@samsung.com]=20
	> Sent: April 19, 2005 8:29 PM=20
	> To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hartman';=20
	> Soukup, Martin [CAR:5K50:EXCH]=20
	> Cc: isms@ietf.org; radiusext@ops.ietf.org; eap@frascone.com=20
	> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party=20
	>=20
	>=20
	> Glen,=20
	>=20
	> > > what is radius for you? (you write that it is not a trusted third =

	> > > party.)=20
	> >=20
	> > It's not.  >From the point of view of authentication protocols =
(PAP,=20
	> > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":=20
	>=20
	> What happens when we look at this picture from the=20
	> "authorization" perspective? "Host-to-NAS authorization for=20
	> the network access service" is dynamically generated from=20
	> "host-to-AAA server" authorization and "AAA server to client=20
	> (NAS)" authorization. Wouldn't this constitute a 3-party model?=20
	>=20
	> Alper=20
	>=20
	>=20
	> > the=20
	> > operation of the auth protocols should be exactly the same=20
	> as if they=20
	> > terminated in the AAA client, instead of elsewhere.  Basically, the =

	> > purpose of AAA (again, from the POV of an authentication=20
	> > protocol) is simply scaling.  BTW, a lot of misery has been=20
	> caused by=20
	> > the erroneous belief that EAP is (or can be) a three-party=20
	> > authentication protocol: it isn't, and can't be.  It could=20
	> _carry_ a=20
	> > three-party protocol (like Kerberos), but EAP in itself is=20
	> a two-party=20
	> > protocol.=20
	> >=20
	> > > why do you care that only one party knows that radius is used? it =

	> > > could also be diameter.=20
	> > >=20
	> > > i would like to better understand why some people dislike the aaa =

	> > > architecture (radius, diameter).=20
	> >=20
	> > I think that the misunderstanding mentioned above might=20
	> have something=20
	> > to do with it...=20
	> >=20
	> > >=20
	> > > ciao=20
	> > > hannes=20
	> > >=20
	> > >=20
	> > >> -----Urspr=FCngliche Nachricht-----=20
	> > >> Von: isms-bounces@lists.ietf.org=20
	> > >> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman=20
	> > >> Gesendet: Freitag, 15. April 2005 19:34=20
	> > >> An: Martin Soukup=20
	> > >> Cc: isms@ietf.org=20
	> > >> Betreff: [Isms] RADIUS is not a trusted third party=20
	> > >>=20
	> > >>=20
	> > >>>>>>> "Martin" =3D=3D Martin Soukup <msoukup@nortel.com> writes:=20
	> > >>=20
	> > >>     Martin> RADIUS "Access-Accept" indicates a successful=20
	> > >>     Martin> authenthentication response for a user.=20
	> > >>=20
	> > >>     Martin> The Access-Accept already returns a=20
	> > "Session-Timeout",=20
	> > >>     Martin> defined as "Sets the maximum number of seconds of=20
	> > service=20
	> > >>     Martin> to be provided to the user before the session=20
	> > >>     Martin> terminates. This attribute value becomes the =
per-user=20
	> > >>     Martin> "absolute timeout."".=20
	> > >>=20
	> > >> This only tells the SNMP engine talking to the RADIUS server the =

	> > >> timeout.  You need to tell the other side of the exchange the=20
	> > >> timeout too.=20
	> > >>=20
	> > >> Remember that RADIUS is a callout service; it is not a trusted=20
	> > third=20
	> > >> party.  In other words, in a particular SNMP authentication, =
only=20
	> > one=20
	> > >> of the parties will know that RADIUS is being used.=20
	> > >>=20
	> > >>=20
	> > >> _______________________________________________=20
	> > >> Isms mailing list=20
	> > >> Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms=20
	> > >>=20
	> > >=20
	> > > _______________________________________________=20
	> > > Isms mailing list=20
	> > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms=20
	> >=20
	> > Hope this helps,=20
	> >=20
	> > ~gwz=20
	> >=20
	> > Why is it that most of the world's problems can't be solved=20
	> by simply=20
	> >   listening to John Coltrane? -- Henry Gabriel=20
	> > _______________________________________________=20
	> > eap mailing list=20
	> > eap@frascone.com=20
	> > http://mail.frascone.com/mailman/listinfo/eap=20
	>=20
	>=20
	>=20
	>=20


------_=_NextPart_001_01C5467A.BE0BC077
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third =
party</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1492" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D647010114-21042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Does=20
the "authenticating entity" know about the RADIUS? IMHO yes it does =
because in=20
EAPv2 that's who it runs the EAP method with.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> isms-bounces@lists.ietf.org=20
  [mailto:isms-bounces@lists.ietf.org] <B>On Behalf Of </B>Glen Zorn=20
  (gwz)<BR><B>Sent:</B> Tuesday, April 19, 2005 9:05 PM<BR><B>To:</B> =
'Martin=20
  Soukup'; 'Alper Yegin'; 'Tschofenig Hannes'; 'Sam =
Hartman'<BR><B>Cc:</B>=20
  isms@ietf.org; eap@frascone.com; =
radiusext@ops.ietf.org<BR><B>Subject:</B> RE:=20
  [eap] RE: [Isms] RADIUS is not a trusted third =
party<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT size=3D2>I definitely look at RADIUS =
as a trusted=20
  third party:</FONT> </DIV>
  <P><FONT size=3D2>Parties involved:</FONT> </P>
  <P><FONT size=3D2>- authenticating entity (user/application)</FONT> =
<BR><FONT=20
  size=3D2>- authenticator/policy enforcement point (device)</FONT> =
<BR><FONT=20
  size=3D2>- authoritative authentication source/policy decision point=20
  (RADIUS)</FONT>&nbsp;<SPAN class=3D877425900-20042005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D877425900-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
  order for a "trusted third party" in the technical sense to exist, the =
other=20
  two parties need to a) know about&nbsp;its existence and b) trust =
it.&nbsp;=20
  Does the "authenticating entity"</FONT>&nbsp;<FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>know about the RADIUS server?&nbsp; </FONT></SPAN></P>
  <P><FONT size=3D2>Martin.</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Alper Yegin [<A=20
  =
href=3D"mailto:alper.yegin@samsung.com">mailto:alper.yegin@samsung.com</A=
>]=20
  </FONT><BR><FONT size=3D2>&gt; Sent: April 19, 2005 8:29 PM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hartman';=20
  </FONT><BR><FONT size=3D2>&gt; Soukup, Martin [CAR:5K50:EXCH]</FONT> =
<BR><FONT=20
  size=3D2>&gt; Cc: isms@ietf.org; radiusext@ops.ietf.org; =
eap@frascone.com</FONT>=20
  <BR><FONT size=3D2>&gt; Subject: RE: [eap] RE: [Isms] RADIUS is not a =
trusted=20
  third party</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Glen,</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; what is radius for you? (you =
write that=20
  it is not a trusted third</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;=20
  party.)</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  It's not.&nbsp; &gt;From the point of view of authentication protocols =
(PAP,=20
  </FONT><BR><FONT size=3D2>&gt; &gt; CHAP, EAP, etc.), both RADIUS and =
Diameter=20
  are just "wires":</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  What happens when we look at this picture from the </FONT><BR><FONT=20
  size=3D2>&gt; "authorization" perspective? "Host-to-NAS authorization =
for=20
  </FONT><BR><FONT size=3D2>&gt; the network access service" is =
dynamically=20
  generated from </FONT><BR><FONT size=3D2>&gt; "host-to-AAA server" =
authorization=20
  and "AAA server to client </FONT><BR><FONT size=3D2>&gt; (NAS)" =
authorization.=20
  Wouldn't this constitute a 3-party model?</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Alper</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
the</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; operation of the auth protocols should be =
exactly=20
  the same </FONT><BR><FONT size=3D2>&gt; as if they </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; terminated in the AAA client, instead of elsewhere.&nbsp; =
Basically, the=20
  </FONT><BR><FONT size=3D2>&gt; &gt; purpose of AAA (again, from the =
POV of an=20
  authentication</FONT> <BR><FONT size=3D2>&gt; &gt; protocol) is simply =

  scaling.&nbsp; BTW, a lot of misery has been </FONT><BR><FONT =
size=3D2>&gt;=20
  caused by </FONT><BR><FONT size=3D2>&gt; &gt; the erroneous belief =
that EAP is=20
  (or can be) a three-party </FONT><BR><FONT size=3D2>&gt; &gt; =
authentication=20
  protocol: it isn't, and can't be.&nbsp; It could </FONT><BR><FONT =
size=3D2>&gt;=20
  _carry_ a </FONT><BR><FONT size=3D2>&gt; &gt; three-party protocol =
(like=20
  Kerberos), but EAP in itself is </FONT><BR><FONT size=3D2>&gt; a =
two-party=20
  </FONT><BR><FONT size=3D2>&gt; &gt; protocol.</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt; why do you care that only one =
party=20
  knows that radius is used? it </FONT><BR><FONT size=3D2>&gt; &gt; &gt; =
could=20
  also be diameter.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; i would like to better understand why some =
people=20
  dislike the aaa </FONT><BR><FONT size=3D2>&gt; &gt; &gt; architecture =
(radius,=20
  diameter).</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  I think that the misunderstanding mentioned above might =
</FONT><BR><FONT=20
  size=3D2>&gt; have something </FONT><BR><FONT size=3D2>&gt; &gt; to do =
with=20
  it...</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; ciao</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; hannes</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;=20
  -----Urspr=FCngliche Nachricht-----</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;&gt;=20
  Von: isms-bounces@lists.ietf.org </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  [<A=20
  =
href=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.iet=
f.org</A>]=20
  Im Auftrag von Sam Hartman</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  Gesendet: Freitag, 15. April 2005 19:34</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;&gt; An: Martin Soukup</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt; Cc:=20
  isms@ietf.org</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; Betreff: =
[Isms]=20
  RADIUS is not a trusted third party</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT =

  size=3D2>&gt; &gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; "Martin" =3D=3D Martin =
Soukup=20
  &lt;msoukup@nortel.com&gt; writes:</FONT> <BR><FONT size=3D2>&gt; &gt; =

  &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Martin&gt; RADIUS "Access-Accept" indicates a successful</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt;=20
  authenthentication response for a user.</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Martin&gt; The Access-Accept already returns a</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; "Session-Timeout",</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; defined as "Sets the =
maximum=20
  number of seconds of</FONT> <BR><FONT size=3D2>&gt; &gt; =
service</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
Martin&gt; to be=20
  provided to the user before the session</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; terminates. This attribute =
value=20
  becomes the per-user</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Martin&gt; "absolute =
timeout."".</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;&gt;=20
  This only tells the SNMP engine talking to the RADIUS server the=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; timeout.&nbsp; You need =
to tell the=20
  other side of the exchange the </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  timeout too.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; Remember that RADIUS is a callout service; =
it is not=20
  a trusted</FONT> <BR><FONT size=3D2>&gt; &gt; third</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt;&gt; party.&nbsp; In other words, in a particular SNMP=20
  authentication, only</FONT> <BR><FONT size=3D2>&gt; &gt; one</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; of the parties will know that RADIUS is =
being=20
  used.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt;&gt; Isms mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  Isms@lists.ietf.org <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
  target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; Isms mailing list</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;=20
  Isms@lists.ietf.org <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
  target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hope this =
helps,</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
~gwz</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Why =
is it that=20
  most of the world's problems can't be solved </FONT><BR><FONT =
size=3D2>&gt; by=20
  simply</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; listening to =
John=20
  Coltrane? -- Henry Gabriel</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; eap mailing list</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  eap@frascone.com</FONT> <BR><FONT size=3D2>&gt; &gt; <A=20
  href=3D"http://mail.frascone.com/mailman/listinfo/eap"=20
  =
target=3D_blank>http://mail.frascone.com/mailman/listinfo/eap</A></FONT> =

  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5467A.BE0BC077--


--===============0434720099==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0434720099==--




From isms-bounces@lists.ietf.org Thu Apr 21 11:37:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOdkb-0001w1-Pk; Thu, 21 Apr 2005 11:37:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOdkb-0001vw-0q
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 11:37:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09931
	for <isms@ietf.org>; Thu, 21 Apr 2005 11:37:55 -0400 (EDT)
Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOdvx-0002Wz-Uk
	for isms@ietf.org; Thu, 21 Apr 2005 11:49:47 -0400
Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124])
	by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j3LFbnZC021644
	for <isms@ietf.org>; Thu, 21 Apr 2005 11:37:49 -0400 (EDT)
Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan
	Messaging Security Suite; Thu, 21 Apr 2005 11:37:49 -0400
Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; 
	Thu, 21 Apr 2005 11:37:48 -0400
Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with
	Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Apr 2005 11:37:32 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 11:37:31 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVGeu4LuIyGq08NS52QCNwpTEVr1wAC1QGw
From: "Nelson, David" <dnelson@enterasys.com>
To: <isms@ietf.org>, <eap@frascone.com>, <radiusext@ops.ietf.org>
X-OriginalArrivalTime: 21 Apr 2005 15:37:32.0116 (UTC)
	FILETIME=[0872B940:01C54688]
X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8
X-pstn-levels: (C:81.6251 M:98.8113 P:95.9108 R:95.9108 S:28.3843 )
X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13
X-pstn-addresses: from <dnelson@enterasys.com> forward (org good) 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Apler Yegin writes...

> I guess the AAA protocol that runs between the NAS and AAA server is a
> "wire" as you said, but the AAA server is the trusted third party.
Does
> this make sense?

I think there is a subtle difference between a "trusted third party" and
a RADIUS server which may have bi-lateral trust relationships with
various parties.  The RADIUS server will always have a trust
relationship with its enrolled Radius clients, via the shared secret.
Those clients may be NASes or they may be RADIUS proxy servers.  RADIUS
trust is always hop-by-hop.

Strictly speaking, the RADIUS server has a trust relationship with the
human user only when the native RADIUS password database is used as the
source of authentication credentials.  Most often, the RADIUS server
relies on some other authentication service (e.g. Active Directory,
LDAP, NIS, etc.).  One tends to think of this as a single entity, and
for certain purposes this is fine.  For other purposes, we need to
retain the distinction.

The host (e.g. via a machine certificate) may also have a trust
relationship, but once again this relationship is typically with an EAP
server "attached" to the Radius server, which may in turn rely on other
authentication services.

A more typical example of a "trusted third party" is a Kerberos KDC
which does in fact directly share credentials with all enrolled
principals (human users, hosts or applications).


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 13:42:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOfh5-00032l-48; Thu, 21 Apr 2005 13:42:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOfh3-00032f-LQ
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 13:42:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20900
	for <isms@ietf.org>; Thu, 21 Apr 2005 13:42:22 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOfsV-0005xA-QD
	for isms@ietf.org; Thu, 21 Apr 2005 13:54:17 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 21 Apr 2005 10:38:05 -0700
X-IronPort-AV: i="3.92,121,1112598000"; 
	d="scan'208"; a="252903836:sNHT993912424"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LHbD3a009673;
	Thu, 21 Apr 2005 10:38:03 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 21 Apr 2005 10:38:02 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 10:38:01 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F8B5@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVGeu4LuIyGq08NS52QCNwpTEVr1wAC1QGwAALjfNA=
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Nelson, David" <dnelson@enterasys.com>, <isms@ietf.org>
X-OriginalArrivalTime: 21 Apr 2005 17:38:02.0402 (UTC)
	FILETIME=[DE08D020:01C54698]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org


> -----Original Message-----
> From: Nelson, David
>=20
> Apler Yegin writes...
> > I guess the AAA protocol that runs between the NAS and AAA server is
a=20
> > "wire" as you said, but the AAA server is the trusted third party.
> > Does this make sense?
>=20
> I think there is a subtle difference between a "trusted third=20
> party" and a RADIUS server which may have bi-lateral trust=20
> relationships with various parties.  The RADIUS server will=20
> always have a trust relationship with its enrolled Radius=20
> clients, via the shared secret.

David made a good point.  RADIUS (and TACACS+) servers and clients
establish multual trust via shared secrets.  I am not sure about
Radius, but in tacacs+ config, a pre-shared key needs to be=20
configured for each pair of AAA server-client.

So in a sense, using RADIUS for SNMP authentication is not quite=20
a solution because you just move the trust/auth problem from one=20
place to another: instead of auth between SNMP entities, you do=20
auth between SNMP entity and RADIUS server. =20

BTW if we can use the pre-shared key(PSK) method to establish trust=20
b/w RADIUS and SNMP entity, why don't we do the samething to auth=20
among SNMP entities directly w/out the need for a third party?
SNMP entities *already* have some shared secrets: user passwords or=20
community strings (so you don't need to configure additional keys=20
as in RADIUS).  So why don't we leverage these shared secrets to=20
auth not only users but also SNMP devices? And that's the motivation
behind the Localized PSK proposal.

Back to the original topic, using RADIUS as an optional AAA tool to=20
facilitate SNMP user management is fine, but it should not be a MUST=20
for SNMP auth, IMHO.

Khanh







_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 13:56:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOfuh-0004LM-2C; Thu, 21 Apr 2005 13:56:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOfuf-0004LH-Nr
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 13:56:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22068
	for <isms@ietf.org>; Thu, 21 Apr 2005 13:56:28 -0400 (EDT)
Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOg68-0006Hx-0t
	for isms@ietf.org; Thu, 21 Apr 2005 14:08:21 -0400
Received: (from uucp@localhost)
	by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA09792
	for <isms@ietf.org>; Thu, 21 Apr 2005 13:57:27 -0400 (EDT)
Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap
	(4.1) id xma009776; Thu, 21 Apr 05 13:56:53 -0400
Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by
	134.141.79.124 with InterScan Messaging Security Suite;
	Thu, 21 Apr 2005 13:55:50 -0400
Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; 
	Thu, 21 Apr 2005 13:55:50 -0400
Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with
	Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Apr 2005 13:55:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 13:55:48 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D8@MAANDMBX2.ets.enterasys.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVGeu4LuIyGq08NS52QCNwpTEVr1wAC1QGwAALjfNAAAlF1UA==
From: "Nelson, David" <dnelson@enterasys.com>
To: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>, <isms@ietf.org>
X-OriginalArrivalTime: 21 Apr 2005 17:55:49.0897 (UTC)
	FILETIME=[5A4F9F90:01C5469B]
X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8
X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:37.2264 )
X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13
X-pstn-addresses: from <dnelson@enterasys.com> forward (org good) 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Khanh Nguyen writes...

> ...why don't we do the samething to auth
> among SNMP entities directly w/out the need for a third party?

I think that's what we have today -- USM -- that operator's find to be
onerous to deploy and manage.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 14:26:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOgNm-0007Yf-Te; Thu, 21 Apr 2005 14:26:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgNl-0007YX-AO
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 14:26:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24338
	for <isms@ietf.org>; Thu, 21 Apr 2005 14:26:32 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOgZE-0006xu-T9
	for isms@ietf.org; Thu, 21 Apr 2005 14:38:25 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 21 Apr 2005 11:26:24 -0700
X-IronPort-AV: i="3.92,121,1112598000"; 
	d="scan'208"; a="252931314:sNHT31116080"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3LIPfiO018411;
	Thu, 21 Apr 2005 11:26:16 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 21 Apr 2005 11:26:15 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 11:26:14 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F8C5@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVGeu4LuIyGq08NS52QCNwpTEVr1wAC1QGwAALjfNAAAlF1UAAAHpWg
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Nelson, David" <dnelson@enterasys.com>, <isms@ietf.org>
X-OriginalArrivalTime: 21 Apr 2005 18:26:15.0487 (UTC)
	FILETIME=[9A728CF0:01C5469F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

=20

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com]=20
> Sent: Thursday, April 21, 2005 10:56 AM
> To: Khanh Nguyen (khanhvn); isms@ietf.org
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
>=20
> Khanh Nguyen writes...
>=20
> > ...why don't we do the samething to auth among SNMP=20
> entities directly=20
> > w/out the need for a third party?
>=20
> I think that's what we have today -- USM -- that operator's=20
> find to be onerous to deploy and manage.
>=20

I understand that.  That's why the LPSK proposal was designed to=20
be able to use SNMP community strings as well as user passwds to=20
generate PSKs.  The concept of "users" actually are from the=20
View-based Access Control model (RFC 3415), and LPSK just tries=20
to support that model, and it does not add any extra config burden=20
(the LPSK values are generated automatically from user & device=20
info w/out any manual interventions)

If operators find the view-based model too complex to use, they
can always use LPSK based on community strings.  In this case,
LPSK configuration is not any more complex than SNMPv1, (but much=20
more secure.)

There are other differences b/w LPSK and USM, but that's another topic.=20

Khanh

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 14:40:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOgbg-0000iW-Da; Thu, 21 Apr 2005 14:40:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgSR-0007yq-MQ
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 14:31:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24718
	for <isms@ietf.org>; Thu, 21 Apr 2005 14:31:22 -0400 (EDT)
Received: from intolerance.mr.itd.umich.edu ([141.211.14.78])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgdu-00075t-VJ
	for isms@ietf.org; Thu, 21 Apr 2005 14:43:15 -0400
Received: from [10.0.1.2] (pm454-05.dialip.mich.net [204.39.226.207])
	by intolerance.mr.itd.umich.edu (smtp) with ESMTP id j3LIVBoh018290;
	Thu, 21 Apr 2005 14:31:12 -0400
In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <fc12c7d7f7e1e3fe79081737d2cb7138@umich.edu>
Content-Transfer-Encoding: 7bit
From: John Vollbrecht <jrv@umich.edu>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 14:31:31 -0400
To: "Nelson, David" <dnelson@enterasys.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 21 Apr 2005 14:40:55 -0400
Cc: John Vollbrecht <jrv@umich.edu>, radiusext@ops.ietf.org, eap@frascone.com,
	isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Nice explanation David.  I have clarifying question below -

On Apr 21, 2005, at 11:37 AM, Nelson, David wrote:

> Apler Yegin writes...
>
>> I guess the AAA protocol that runs between the NAS and AAA server is a
>> "wire" as you said, but the AAA server is the trusted third party.
> Does
>> this make sense?
>
> I think there is a subtle difference between a "trusted third party" 
> and
> a RADIUS server which may have bi-lateral trust relationships with
> various parties.  The RADIUS server will always have a trust
> relationship with its enrolled Radius clients, via the shared secret.
> Those clients may be NASes or they may be RADIUS proxy servers.  RADIUS
> trust is always hop-by-hop.
>
> Strictly speaking, the RADIUS server has a trust relationship with the
> human user only when the native RADIUS password database is used as the
> source of authentication credentials.  Most often, the RADIUS server
> relies on some other authentication service (e.g. Active Directory,
> LDAP, NIS, etc.).  One tends to think of this as a single entity, and
> for certain purposes this is fine.  For other purposes, we need to
> retain the distinction.
>
> The host (e.g. via a machine certificate) may also have a trust
> relationship, but once again this relationship is typically with an EAP
> server "attached" to the Radius server, which may in turn rely on other
> authentication services.
The question I am wondering about is whether the RADIUS server could be 
a  trusted third party if it is directly connected to the NAS.  In that 
case it has credentials with all parties.  However the credentials are 
of quite different form - I am wondering if the form of credentials or 
the relationship between the credentials makes a difference in whether 
it can act effectively as a trusted third party.  My first guess  is 
that it could (especially if RADIUS had stronger hashing) but I am not 
sure.
What is your thought?

> A more typical example of a "trusted third party" is a Kerberos KDC
> which does in fact directly share credentials with all enrolled
> principals (human users, hosts or applications).
>
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>
>


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 16:17:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOi7I-0007Uq-CU; Thu, 21 Apr 2005 16:17:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOi7H-0007TZ-2r
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 16:17:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11481
	for <isms@ietf.org>; Thu, 21 Apr 2005 16:17:37 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOiIk-0003xy-I9
	for isms@ietf.org; Thu, 21 Apr 2005 16:29:31 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3LKHUQO028810
	for <isms@ietf.org>; Thu, 21 Apr 2005 16:17:31 -0400 (EDT)
Message-Id: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Thu, 21 Apr 2005 16:17:32 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: 
Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

ISMS members,

There's been a lot of discussion recently on the mailing list about the
pros and cons of different security models.  I think the discussion has
been good, but unfortunately I don't think it's getting any closer to a
consensus (I thank Robert for trying to draw things closer;
unfortunately Juergen and I have been rather busy off-line, and I
apologize for that).  I know that some on the mailing list have
expressed a preference for choosing a security protocol first, but
we've been tasked with choosing the architecture first, and I believe
that is the appropriate approach.

Anyway, I'd like to call for a consensus on the security architecture.
As we all know, the three choices are:

- Out of band keying (the architecture used by EUSM)
- In-bakd keying (the architecture used by SBSM)
- Encapsulation keying (the architecture used by TLSM)

What I would like to see is WG members express which architecture(s)
they prefer (you can choose more than one, but please, don't choose all
three).  Please feel free to state your reasons for your choices, but
in the interests of reaching consensus in a reasonable timeframe, I am
asking that WG members please refrain from commenting on other people's
choices unless they feel that the person has stated a fact which is
obviously wrong.

Thanks for your time,

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 16:56:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOiix-0007Ol-9O; Thu, 21 Apr 2005 16:56:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOiir-0007OP-Jy
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 16:56:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15064
	for <isms@ietf.org>; Thu, 21 Apr 2005 16:56:04 -0400 (EDT)
Message-Id: <200504212056.QAA15064@ietf.org>
Received: from rwcrmhc11.comcast.net ([204.127.198.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOitu-0004yO-FA
	for isms@ietf.org; Thu, 21 Apr 2005 17:07:59 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc11) with SMTP
	id <2005042120551801300rknabe>; Thu, 21 Apr 2005 20:55:18 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Ken Hornstein'" <kenh@cmf.nrl.navy.mil>, <isms@ietf.org>
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Thu, 21 Apr 2005 16:55:10 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVGr2eGfVEmjkHtQ1utTN6ZdUfGWAAA6jjw
In-Reply-To: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Can I suggest that people express their opinions for each proposed
architecure as either 1) I support this approach (for, in Robert's
summary)
2) I could accept this approach even though I consider it suboptimal
(maybe)
3) I strongly object to this approach (against)

I suggest this because I would like to reduce the amount of
interpretation done by the person gathering the info. My prior
comments lead to my opinions being categorized as for-against-againt,
when they should have been for-maybe-maybe.

We should require the reasons be stated for "strongly object" so the
WG can consider whether that point really should be a show-stopper
(e.g. EAP WG says no to EAP proposal, or TLSM requires TCP rather than
UDP, etc), and whether it is possible to make different choices within
that architecture to address the show-stopper concerns.

dbh

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein
> Sent: Thursday, April 21, 2005 4:18 PM
> To: isms@ietf.org
> Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> ISMS members,
> 
> There's been a lot of discussion recently on the mailing list 
> about the
> pros and cons of different security models.  I think the 
> discussion has
> been good, but unfortunately I don't think it's getting any 
> closer to a
> consensus (I thank Robert for trying to draw things closer;
> unfortunately Juergen and I have been rather busy off-line, and I
> apologize for that).  I know that some on the mailing list have
> expressed a preference for choosing a security protocol first, but
> we've been tasked with choosing the architecture first, and I
believe
> that is the appropriate approach.
> 
> Anyway, I'd like to call for a consensus on the security
architecture.
> As we all know, the three choices are:
> 
> - Out of band keying (the architecture used by EUSM)
> - In-bakd keying (the architecture used by SBSM)
> - Encapsulation keying (the architecture used by TLSM)
> 
> What I would like to see is WG members express which architecture(s)
> they prefer (you can choose more than one, but please, don't 
> choose all
> three).  Please feel free to state your reasons for your choices,
but
> in the interests of reaching consensus in a reasonable timeframe, I
am
> asking that WG members please refrain from commenting on 
> other people's
> choices unless they feel that the person has stated a fact which is
> obviously wrong.
> 
> Thanks for your time,
> 
> --Ken
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 17:33:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOjJ9-0004UN-2O; Thu, 21 Apr 2005 17:33:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjIx-0004Om-M2
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 17:33:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17373
	for <isms@ietf.org>; Thu, 21 Apr 2005 17:33:45 -0400 (EDT)
Received: from i9a30.i.pppool.de ([85.73.154.48] helo=boskop.local)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOjUR-0005mZ-B5
	for isms@ietf.org; Thu, 21 Apr 2005 17:45:40 -0400
Received: by boskop.local (Postfix, from userid 501)
	id 30C4D29F71F; Thu, 21 Apr 2005 23:33:32 +0200 (CEST)
Date: Thu, 21 Apr 2005 23:33:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: David B Harrington <ietfdbh@comcast.net>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Message-ID: <20050421213332.GA18953@boskop.local>
Mail-Followup-To: David B Harrington <ietfdbh@comcast.net>,
	'Ken Hornstein' <kenh@cmf.nrl.navy.mil>, isms@ietf.org
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
	<200504212056.QAA15064@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200504212056.QAA15064@ietf.org>
User-Agent: Mutt/1.5.8i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

On Thu, Apr 21, 2005 at 04:55:10PM -0400, David B Harrington wrote:

> We should require the reasons be stated for "strongly object" so the
> WG can consider whether that point really should be a show-stopper
> (e.g. EAP WG says no to EAP proposal, or TLSM requires TCP rather than
> UDP, etc), and whether it is possible to make different choices within
> that architecture to address the show-stopper concerns.

Hey, now you are talking about protocols. We are not supposed to do
that. Just architecture. :-)

/js

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

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 17:39:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOjOM-0005Do-Ug; Thu, 21 Apr 2005 17:39:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjOL-0005Dj-77
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 17:39:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17856
	for <isms@ietf.org>; Thu, 21 Apr 2005 17:39:18 -0400 (EDT)
Received: from blaster.systems.pipex.net ([62.241.163.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOjZp-0005vE-BE
	for isms@ietf.org; Thu, 21 Apr 2005 17:51:14 -0400
Received: from pc6 (1Cust110.tnt24.lnd4.gbr.da.uu.net [62.188.151.110])
	by blaster.systems.pipex.net (Postfix) with SMTP id 8E2D6E0001EC;
	Thu, 21 Apr 2005 22:39:05 +0100 (BST)
Message-ID: <031401c546b1$a988d5c0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Nelson, David" <dnelson@enterasys.com>,
	"Khanh Nguyen (khanhvn)" <khanhvn@cisco.com>, <isms@ietf.org>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D8@MAANDMBX2.ets.enterasys.com>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 22:35:14 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

I'm with Khanh on this one.  We could have a system whereby the setup of 'USM'
was much simpler, users with fixed names, passwords being input at agent setup,
no need for any contact between agent and third party; and changing the
behaviour
of the manager to fit in with this.  The manager is the easy part because it is
on a server already replete with security systems - (almost) anything is
possible there, like requiring authorisation to send packets to port 161/162 if
that is what the security demands.
.
Tom Petch

----- Original Message -----
From: "Nelson, David" <dnelson@enterasys.com>
To: "Khanh Nguyen (khanhvn)" <khanhvn@cisco.com>; <isms@ietf.org>
Sent: Thursday, April 21, 2005 7:55 PM
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party


Khanh Nguyen writes...

> ...why don't we do the samething to auth
> among SNMP entities directly w/out the need for a third party?

I think that's what we have today -- USM -- that operator's find to be
onerous to deploy and manage.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 17:44:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOjTd-00067o-Tm; Thu, 21 Apr 2005 17:44:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjTc-00067j-CK
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 17:44:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18879
	for <isms@ietf.org>; Thu, 21 Apr 2005 17:44:46 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOjf5-0006BW-QV
	for isms@ietf.org; Thu, 21 Apr 2005 17:56:41 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3LLiPR4019526; 
	Thu, 21 Apr 2005 21:44:26 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3LLiNM0026009; 
	Thu, 21 Apr 2005 21:44:25 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042114442528178 ; Thu, 21 Apr 2005 14:44:25 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 14:44:25 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 14:44:25 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 17:44:23 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 17:43:59 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVGuptYh9ssGLtOTsGfMq19C54fXQAAEKKw
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>,
	"Nelson, David" <dnelson@enterasys.com>,
	"Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>, <isms@ietf.org>
X-OriginalArrivalTime: 21 Apr 2005 21:44:23.0766 (UTC)
	FILETIME=[4869F760:01C546BB]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

But that was the whole problem! Admins did NOT want to enter a new set
of user-names and passwords in each agent, and then manage the lists.
The purpose of the linkage with RADIUS or such is to re-use the name
lists that are already there (no need to re-type) and the keys that are
already there (no need to re-key).

It's how EXACTLY to accomplish this, and WHAT existing infrastructures
to connect to, that people are arguing about bitterly here and now.=20

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Tom Petch
Sent: Thursday, April 21, 2005 4:35 PM
To: Nelson, David; Khanh Nguyen (khanhvn); isms@ietf.org
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party

I'm with Khanh on this one.  We could have a system whereby the setup of
'USM'
was much simpler, users with fixed names, passwords being input at agent
setup,
no need for any contact between agent and third party; and changing the
behaviour
of the manager to fit in with this.  The manager is the easy part
because it is
on a server already replete with security systems - (almost) anything is
possible there, like requiring authorisation to send packets to port
161/162 if
that is what the security demands.
.
Tom Petch

----- Original Message -----
From: "Nelson, David" <dnelson@enterasys.com>
To: "Khanh Nguyen (khanhvn)" <khanhvn@cisco.com>; <isms@ietf.org>
Sent: Thursday, April 21, 2005 7:55 PM
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party


Khanh Nguyen writes...

> ...why don't we do the samething to auth
> among SNMP entities directly w/out the need for a third party?

I think that's what we have today -- USM -- that operator's find to be
onerous to deploy and manage.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 17:49:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOjYW-00071A-2R; Thu, 21 Apr 2005 17:49:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjYU-00070v-3M
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 17:49:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19376
	for <isms@ietf.org>; Thu, 21 Apr 2005 17:49:47 -0400 (EDT)
Received: from moby.atcorp.com ([204.72.172.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOjjy-0006L1-Ax
	for isms@ietf.org; Thu, 21 Apr 2005 18:01:43 -0400
Received: from conger.atcorp.com ([204.72.172.102] helo=STRIPER)
	by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian))
	id 1DOjYE-0004i4-00; Thu, 21 Apr 2005 16:49:34 -0500
From: "Wayne Kading" <wkading@atcorp.com>
To: <isms@ietf.org>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 16:49:32 -0500
Organization: ATC
Message-ID: <004401c546bc$00c25960$84aca8c0@STRIPER>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <BC5CFB047387BD41AC606027302F1FDD13F8C5@xmb-sjc-22e.amer.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

It seems to me that the LPSK instantiation for the TLSM architecture is an
attractive ease-of-use feature for the operators, with or without VACM.  If
so, this feature could considerably broaden the SNMPv3 user base.

Wayne

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Khanh Nguyen (khanhvn)
Sent: Thursday, April 21, 2005 1:26 PM
To: Nelson, David; isms@ietf.org
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

 

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Thursday, April 21, 2005 10:56 AM
> To: Khanh Nguyen (khanhvn); isms@ietf.org
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> Khanh Nguyen writes...
> 
> > ...why don't we do the samething to auth among SNMP 
> entities directly 
> > w/out the need for a third party?
> 
> I think that's what we have today -- USM -- that operator's 
> find to be onerous to deploy and manage.
> 

I understand that.  That's why the LPSK proposal was designed to 
be able to use SNMP community strings as well as user passwds to 
generate PSKs.  The concept of "users" actually are from the 
View-based Access Control model (RFC 3415), and LPSK just tries 
to support that model, and it does not add any extra config burden 
(the LPSK values are generated automatically from user & device 
info w/out any manual interventions)

If operators find the view-based model too complex to use, they
can always use LPSK based on community strings.  In this case,
LPSK configuration is not any more complex than SNMPv1, (but much 
more secure.)

There are other differences b/w LPSK and USM, but that's another topic. 

Khanh

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 18:34:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOkFK-0005m0-Nw; Thu, 21 Apr 2005 18:34:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOkFK-0005lM-21
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 18:34:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25026
	for <isms@ietf.org>; Thu, 21 Apr 2005 18:34:03 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOkQo-0007bb-R6
	for isms@ietf.org; Thu, 21 Apr 2005 18:46:00 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id C39EE11D944; Thu, 21 Apr 2005 15:33:57 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Organization: Sparta
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
Date: Thu, 21 Apr 2005 15:33:55 -0700
In-Reply-To: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil> (Ken
	Hornstein's message of "Thu, 21 Apr 2005 16:17:32 -0400")
Message-ID: <sdmzrr4v58.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Thu, 21 Apr 2005 16:17:32 -0400, Ken Hornstein <kenh@cmf.nrl.navy.mil> said:

Ken> - In-bakd keying (the architecture used by SBSM)

For

Ken> - Encapsulation keying (the architecture used by TLSM)

Ok/Maybe (or For if you don't go with David's suggestion)

Ken> - Out of band keying (the architecture used by EUSM)

Strongly against (see points from previous lengthy discussions)

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 21:40:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOnA9-0000VL-Pr; Thu, 21 Apr 2005 21:40:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOnA5-0000TM-2P
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 21:40:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08758
	for <isms@ietf.org>; Thu, 21 Apr 2005 21:40:51 -0400 (EDT)
Received: from c-24-128-127-232.hsd1.ma.comcast.net ([24.128.127.232]
	helo=konishi-polis.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOnLZ-0003j6-H9
	for isms@ietf.org; Thu, 21 Apr 2005 21:52:48 -0400
Received: by konishi-polis.mit.edu (Postfix, from userid 8042)
	id D725915162F; Thu, 21 Apr 2005 21:40:47 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
References: <3DEC199BD7489643817ECA151F7C59290103ED92@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Thu, 21 Apr 2005 21:40:47 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C59290103ED92@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Thu, 21 Apr 2005 10:02:00 -0400")
Message-ID: <tsl1x93eggw.fsf@mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: Alper Yegin <alper.yegin@samsung.com>, isms@ietf.org, eap@frascone.com,
	radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

    Blumenthal,> Does the "authenticating entity" know about the
    Blumenthal,> RADIUS? IMHO yes it does because in EAPv2 that's who
    Blumenthal,> it runs the EAP method with.

Only if there is a radius server.  The EAP peer knows about the EAP
server, but for example does not know whether it is using diameter,
radius or something else.  Thus it does not know about radius per se.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 21:54:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOnMo-0002A0-SW; Thu, 21 Apr 2005 21:54:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOnMm-00029N-Vf
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 21:54:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09390
	for <isms@ietf.org>; Thu, 21 Apr 2005 21:53:59 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOnYK-0003yD-Cu
	for isms@ietf.org; Thu, 21 Apr 2005 22:05:56 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 21 Apr 2005 18:53:52 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3M1r3iY016383;
	Thu, 21 Apr 2005 18:53:49 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 21 Apr 2005 18:53:47 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Thu, 21 Apr 2005 18:53:46 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F917@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVGuptYh9ssGLtOTsGfMq19C54fXQAAEKKwAAcEiCA=
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	"Tom Petch" <nwnetworks@dial.pipex.com>,
	"Nelson, David" <dnelson@enterasys.com>, <isms@ietf.org>
X-OriginalArrivalTime: 22 Apr 2005 01:53:47.0192 (UTC)
	FILETIME=[1F4F9380:01C546DE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

I agree that RADIUS can be very helpful for user configuration.
I just think that it should be an optional, not a required component=20
of SNMP security. =20

RADIUS is helpful for VACM, but if another access control model is used
(e.g. community based), then RADIUS may no longer applicable.  RFC3411=20
allows multiple access control models, so from the architecture point=20
of view, it's prefered that the security model is not dependent on a =20
particular access control model.=20

BTW the LPSK proposal also support RADIUS and other AAA options.
The LPSK values (or the passwords to generate them) can be stored
locally in the devices or remotely in AAA servers such as radius.
Which way to use (local or remote users) is up to the operators, and=20
that's completely transparent to the rest of the model.

Regards.

Khanh

> -----Original Message-----
> From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20
>=20
> But that was the whole problem! Admins did NOT want to enter=20
> a new set of user-names and passwords in each agent, and then=20
> manage the lists.
> The purpose of the linkage with RADIUS or such is to re-use=20
> the name lists that are already there (no need to re-type)=20
> and the keys that are already there (no need to re-key).
>=20
> It's how EXACTLY to accomplish this, and WHAT existing=20
> infrastructures to connect to, that people are arguing about=20
> bitterly here and now.=20
>=20
> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
> On Behalf Of Tom Petch
> Sent: Thursday, April 21, 2005 4:35 PM
> To: Nelson, David; Khanh Nguyen (khanhvn); isms@ietf.org
> Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
>=20
> I'm with Khanh on this one.  We could have a system whereby=20
> the setup of 'USM'
> was much simpler, users with fixed names, passwords being=20
> input at agent setup, no need for any contact between agent=20
> and third party; and changing the behaviour of the manager to=20
> fit in with this.  The manager is the easy part because it is=20
> on a server already replete with security systems - (almost)=20
> anything is possible there, like requiring authorisation to=20
> send packets to port
> 161/162 if
> that is what the security demands.
> .
> Tom Petch
>=20
> ----- Original Message -----
> From: "Nelson, David" <dnelson@enterasys.com>
> To: "Khanh Nguyen (khanhvn)" <khanhvn@cisco.com>; <isms@ietf.org>
> Sent: Thursday, April 21, 2005 7:55 PM
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
>=20
>=20
> Khanh Nguyen writes...
>=20
> > ...why don't we do the samething to auth among SNMP=20
> entities directly=20
> > w/out the need for a third party?
>=20
> I think that's what we have today -- USM -- that operator's=20
> find to be onerous to deploy and manage.
>=20
>=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 22:38:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOo3o-0007ZN-88; Thu, 21 Apr 2005 22:38:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOo3m-0007ZD-PL
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 22:38:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11649
	for <isms@ietf.org>; Thu, 21 Apr 2005 22:38:24 -0400 (EDT)
Message-Id: <200504220238.WAA11649@ietf.org>
Received: from rwcrmhc14.comcast.net ([216.148.227.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOoFJ-0004q6-Od
	for isms@ietf.org; Thu, 21 Apr 2005 22:50:23 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc14) with SMTP
	id <20050422023813014009seode>; Fri, 22 Apr 2005 02:38:13 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Wes Hardaker'" <hardaker@tislabs.com>,
	"'Ken Hornstein'" <kenh@cmf.nrl.navy.mil>
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Thu, 21 Apr 2005 22:38:05 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVGwn6Chngxz1TXRj6fcVb/QfbFqAAIUtOA
In-Reply-To: <sdmzrr4v58.fsf@wes.hardakers.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi,

In this comment,

> Ken> - Encapsulation keying (the architecture used by TLSM)
> 
> Ok/Maybe (or For if you don't go with David's suggestion)

Which David, and which suggestion?
If me, and the suggestion was how to characterize "maybe", does that
mean you consider Encapsulation keying sub-optimal? I just want to be
sure I understand your comment.

Folks, can we try to be more explicit when referring to previous mail
messages so the intent of your message is clear?

Thanks,
dbh



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 22:48:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOoD9-0000h9-K8; Thu, 21 Apr 2005 22:48:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOoD7-0000fE-SP
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 22:48:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12363
	for <isms@ietf.org>; Thu, 21 Apr 2005 22:48:04 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOoOe-00052q-VJ
	for isms@ietf.org; Thu, 21 Apr 2005 23:00:02 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id A0BF211D944; Thu, 21 Apr 2005 19:48:00 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: <ietfdbh@comcast.net>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Organization: Sparta
References: <200504220234.j3M2YWpn001128@nutshell.tislabs.com>
Date: Thu, 21 Apr 2005 19:48:00 -0700
In-Reply-To: <200504220234.j3M2YWpn001128@nutshell.tislabs.com> (David
	B. Harrington's message of "Thu, 21 Apr 2005 22:38:05 -0400")
Message-ID: <sdis2f4jdr.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Thu, 21 Apr 2005 22:38:05 -0400, "David B Harrington" <ietfdbh@comcast.net> said:

David> If me, and the suggestion was how to characterize "maybe", does
David> that mean you consider Encapsulation keying sub-optimal? I just
David> want to be sure I understand your comment.

Yes, but since I can't qualify as "slightly" then I'd have to say yes
because it doesn't offer as much compatibility.


-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 22:59:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOoO8-0002X4-7Z; Thu, 21 Apr 2005 22:59:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOoO5-0002V6-5M
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 22:59:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13341
	for <isms@ietf.org>; Thu, 21 Apr 2005 22:59:23 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOoZc-0005KO-83
	for isms@ietf.org; Thu, 21 Apr 2005 23:11:21 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 21 Apr 2005 19:59:15 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3M2wXLT012210;
	Thu, 21 Apr 2005 19:59:08 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 21 Apr 2005 19:59:12 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Thu, 21 Apr 2005 19:59:11 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F919@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Thread-Index: AcVGr48aazLM45sURIuPgsIRPnNgmAAMI5yQ
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>, <isms@ietf.org>
X-OriginalArrivalTime: 22 Apr 2005 02:59:12.0202 (UTC)
	FILETIME=[42CC92A0:01C546E7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Sorry if I missed something, but when discussing about the keying
choices,
are we talking about (1) encryption keys or (2) authentication keys?=20

If it's (1), I would vote for inband/encapsulation keying (I think
encaps=20
is basically inband), and strongly oppose out-of-band.  Why need a whole

external, out-of-band infrastructure just to do something that can be
done=20
easily by two Diffie-Hellman key exchange messages (like SSL/TLS has
been doing)

If it's (2), then maybe we first need to decide which 'abstract'
authentication method to be used, before going to the specific=20
keying scheme implementation (some auth method may not need any 'key'):

+ kerberos authentication
+ public-key certificate (e.g. x509)
+ pre-shared key (PSK) auth
+ centralized AAA (e.g. radius)
+ password digest (user auth only)
+ host key files (SSH host auth)
+ etc...

Khanh

> -----Original Message-----
> From: isms-bounces@lists.ietf.org=20
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein
> Sent: Thursday, April 21, 2005 1:18 PM
> To: isms@ietf.org
> Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture
>=20
> ISMS members,
>=20
> There's been a lot of discussion recently on the mailing list=20
> about the pros and cons of different security models.  I=20
> think the discussion has been good, but unfortunately I don't=20
> think it's getting any closer to a consensus (I thank Robert=20
> for trying to draw things closer; unfortunately Juergen and I=20
> have been rather busy off-line, and I apologize for that).  I=20
> know that some on the mailing list have expressed a=20
> preference for choosing a security protocol first, but we've=20
> been tasked with choosing the architecture first, and I=20
> believe that is the appropriate approach.
>=20
> Anyway, I'd like to call for a consensus on the security architecture.
> As we all know, the three choices are:
>=20
> - Out of band keying (the architecture used by EUSM)
> - In-bakd keying (the architecture used by SBSM)
> - Encapsulation keying (the architecture used by TLSM)
>=20
> What I would like to see is WG members express which=20
> architecture(s) they prefer (you can choose more than one,=20
> but please, don't choose all three).  Please feel free to=20
> state your reasons for your choices, but in the interests of=20
> reaching consensus in a reasonable timeframe, I am asking=20
> that WG members please refrain from commenting on other=20
> people's choices unless they feel that the person has stated=20
> a fact which is obviously wrong.
>=20
> Thanks for your time,
>=20
> --Ken
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 21 22:59:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOoOW-0002Yq-DM; Thu, 21 Apr 2005 22:59:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOoOV-0002Yl-TN
	for isms@megatron.ietf.org; Thu, 21 Apr 2005 22:59:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13360
	for <isms@ietf.org>; Thu, 21 Apr 2005 22:59:49 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOoa2-0005LT-Uo
	for isms@ietf.org; Thu, 21 Apr 2005 23:11:48 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DOoOS-0005x7-DZ; Thu, 21 Apr 2005 22:59:48 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3M2xkK29216;
	Thu, 21 Apr 2005 19:59:46 -0700
Date: Thu, 21 Apr 2005 19:59:46 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: "Nelson, David" <dnelson@enterasys.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com>
Message-ID: <Pine.LNX.4.56.0504211947310.28498@internaut.com>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> I think there is a subtle difference between a "trusted third party" and
> a RADIUS server which may have bi-lateral trust relationships with
> various parties.

Yes.  Where RADIUS proxies are present there is no trust relationship
between the NAS and RADIUS server.  This is in contrast to Diameter, where
such a relationship can be established via re-direct.

The distinction is important in a number of cases.  In Kerberos, the KDC
is able to provide a ticket to any principal because it has a shared
secret that it shares with that principle.

Within RADIUS this is not possible.  A RADIUS server cannot
provide the user with a ticket to a NAS because it may not have a trust
relationship with that NAS.

Note that at one point, there was a proposal for integration of RADIUS
with Kerberos.  That proposal did in fact enable RADIUS to become a true
trusted third party.  The proposal seemed practical. However, the AAA WG
went with another proposal (Diameter CMS) which it turned out that noone
wanted to implement. Among other things, the proposal enabled a RADIUS
server to send a key to a NAS that could not be viewed by intervening
proxies.  In retrospect, the IETF may have missed an important
opportunity.

For a trip down memory lane, look here:
http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 00:32:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOpqc-0005qn-SU; Fri, 22 Apr 2005 00:32:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOpqb-0005ou-Gs
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 00:32:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18530
	for <isms@ietf.org>; Fri, 22 Apr 2005 00:32:54 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOq2A-0007Hf-1v
	for isms@ietf.org; Fri, 22 Apr 2005 00:44:54 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3M4VSPR004687; 
	Fri, 22 Apr 2005 04:31:28 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3M4VMa8031902; 
	Fri, 22 Apr 2005 04:31:26 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042121312604131 ; Thu, 21 Apr 2005 21:31:26 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 21:31:26 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 21:31:25 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 22 Apr 2005 00:31:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Fri, 22 Apr 2005 00:30:59 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290103F300@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Thread-Index: AcVGr48aazLM45sURIuPgsIRPnNgmAAMI5yQAAScX6A=
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>,
	"Ken Hornstein" <kenh@cmf.nrl.navy.mil>, <isms@ietf.org>
X-OriginalArrivalTime: 22 Apr 2005 04:31:24.0653 (UTC)
	FILETIME=[246599D0:01C546F4]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> Sorry if I missed something, but when discussing about the keying
> choices,are we talking about (1) encryption keys or (2) authentication
keys?=20

To ask this question correctly, it should sound "are we talking about
short-term keys, or long-term keys to authenticate the exchange/creation
of the short-time keys?"

> just to do something that can be done easily by two Diffie-Hellman key
exchange
> messages (like SSL/TLS has been doing)

You're very generous with computing resources. Even TLS (usually)
doesn't do DH key exchange.

> If it's (2), then maybe we first need to decide which 'abstract'
> authentication method to be used, before going to the specific=20
> keying scheme implementation (some auth method may not need any
'key'):

Very nice - except that the contestants are about equally divided
between these: some need Kerberos, some need PKI, some insist that
*their* "constituency" can deal efficiently only with SSH. And it's not
a big deal to make a code stew to support all of the above and below -
except that it's next to impossible to analyse security property of the
resulting stew. Not that everybody cares, of course...

+ kerberos authentication
+ public-key certificate (e.g. x509)
+ pre-shared key (PSK) auth
+ centralized AAA (e.g. radius)
+ password digest (user auth only)
+ host key files (SSH host auth)
+ etc...

Khanh

> -----Original Message-----
> From: isms-bounces@lists.ietf.org=20
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein
> Sent: Thursday, April 21, 2005 1:18 PM
> To: isms@ietf.org
> Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture
>=20
> ISMS members,
>=20
> There's been a lot of discussion recently on the mailing list=20
> about the pros and cons of different security models.  I=20
> think the discussion has been good, but unfortunately I don't=20
> think it's getting any closer to a consensus (I thank Robert=20
> for trying to draw things closer; unfortunately Juergen and I=20
> have been rather busy off-line, and I apologize for that).  I=20
> know that some on the mailing list have expressed a=20
> preference for choosing a security protocol first, but we've=20
> been tasked with choosing the architecture first, and I=20
> believe that is the appropriate approach.
>=20
> Anyway, I'd like to call for a consensus on the security architecture.
> As we all know, the three choices are:
>=20
> - Out of band keying (the architecture used by EUSM)
> - In-bakd keying (the architecture used by SBSM)
> - Encapsulation keying (the architecture used by TLSM)
>=20
> What I would like to see is WG members express which=20
> architecture(s) they prefer (you can choose more than one,=20
> but please, don't choose all three).  Please feel free to=20
> state your reasons for your choices, but in the interests of=20
> reaching consensus in a reasonable timeframe, I am asking=20
> that WG members please refrain from commenting on other=20
> people's choices unless they feel that the person has stated=20
> a fact which is obviously wrong.
>=20
> Thanks for your time,
>=20
> --Ken
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 00:33:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOpr8-0005u3-0l; Fri, 22 Apr 2005 00:33:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOpr6-0005ty-DU
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 00:33:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18550
	for <isms@ietf.org>; Fri, 22 Apr 2005 00:33:25 -0400 (EDT)
Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOq2e-0007IA-40
	for isms@ietf.org; Fri, 22 Apr 2005 00:45:25 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3M4XAqP017722; 
	Fri, 22 Apr 2005 04:33:10 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3M4X1aC000379; 
	Fri, 22 Apr 2005 04:33:09 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042121330905979 ; Thu, 21 Apr 2005 21:33:09 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 21:33:09 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Apr 2005 21:33:09 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 22 Apr 2005 00:33:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Fri, 22 Apr 2005 00:32:43 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVG56vZVdaMuy7pSyCQXqD77a+3WgADHrkg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Bernard Aboba" <aboba@internaut.com>,
	"Nelson, David" <dnelson@enterasys.com>
X-OriginalArrivalTime: 22 Apr 2005 04:33:07.0795 (UTC)
	FILETIME=[61DFD230:01C546F4]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>Where RADIUS proxies are present there is no trust relationship
>between the NAS and RADIUS server.  This is in contrast to Diameter,
where
>such a relationship can be established via re-direct.
>
>The distinction is important in a number of cases.  In Kerberos, the
KDC
>is able to provide a ticket to any principal because it has a shared
>secret that it shares with that principle.
>
>Within RADIUS this is not possible.  A RADIUS server cannot
>provide the user with a ticket to a NAS because it may not have a trust
>relationship with that NAS.

Yet NAS takes "go/no-go" decision from RADIUS, and takes the keys to
talk to the client... If this is not trust - what is it?

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 00:51:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOq8e-00086w-Uh; Fri, 22 Apr 2005 00:51:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOq8c-00086B-JS
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 00:51:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20099
	for <isms@ietf.org>; Fri, 22 Apr 2005 00:51:31 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOqKA-0007in-Kh
	for isms@ietf.org; Fri, 22 Apr 2005 01:03:31 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DOq8Z-000Ih3-9P; Fri, 22 Apr 2005 00:51:31 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3M4pTp04568;
	Thu, 21 Apr 2005 21:51:29 -0700
Date: Thu, 21 Apr 2005 21:51:29 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>
Message-ID: <Pine.LNX.4.56.0504212145530.4057@internaut.com>
References: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> Yet NAS takes "go/no-go" decision from RADIUS, and takes the keys to
> talk to the client... If this is not trust - what is it?

There is no IETF standard defining how keys are provided within
RADIUS for exactly that reason -- there is no trust relationship defined
when a proxy is present.  The "Housley Criteria" described in RFC 4017 do
not allow disclosure of keys to additional parties.

The problem does not exist in Diameter EAP, which enables keys to
be provided directly without access by proxies.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 02:23:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOrZm-0004UI-Iw; Fri, 22 Apr 2005 02:23:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOrZl-0004U7-81
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 02:23:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15940
	for <isms@ietf.org>; Fri, 22 Apr 2005 02:23:40 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOrlJ-000120-Hb
	for isms@ietf.org; Fri, 22 Apr 2005 02:35:39 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 21 Apr 2005 23:23:30 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3M6NAi8017209;
	Thu, 21 Apr 2005 23:23:28 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 21 Apr 2005 23:23:27 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Thu, 21 Apr 2005 23:23:25 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F923@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Thread-Index: AcVGr48aazLM45sURIuPgsIRPnNgmAAMI5yQAAScX6AAAjaFoA==
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	"Ken Hornstein" <kenh@cmf.nrl.navy.mil>, <isms@ietf.org>
X-OriginalArrivalTime: 22 Apr 2005 06:23:27.0178 (UTC)
	FILETIME=[CB5582A0:01C54703]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

 Pls see line...

> -----Original Message-----
> From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20
> Sent: Thursday, April 21, 2005 9:31 PM
> To: Khanh Nguyen (khanhvn); Ken Hornstein; isms@ietf.org
> Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
>=20
> > Sorry if I missed something, but when discussing about the keying=20
> > choices,are we talking about (1) encryption keys or (2)=20
> authentication
> keys?=20
>=20
> To ask this question correctly, it should sound "are we=20
> talking about short-term keys, or long-term keys to=20
> authenticate the exchange/creation of the short-time keys?"

I am not sure what you mean short/long-term keys, but from the=20
abstract/architectural point of view, securing a communication=20
system generally has two orthogonal domains: (1) encryption +
data integrity and (2) authentication.  The former domain (1)=20
is about communicated data (bits and bytes), while the later (2)=20
is about communicating entities (users/snmp managers/snmp agents). =20
In this architectural discussion, I think it's useful to recognize=20
the differences b/w these two domains.

>=20
> > just to do something that can be done easily by two=20
> > Diffie-Hellman key exchange
> > messages (like SSL/TLS has been doing)
>=20
> You're very generous with computing resources.=20

DH requires an integer exponential and a modulo operation per=20
session.  So I think it's not that computing intensive.  HTTPS
commodity servers now a day can easily handle millions of sessions=20
per day.  Most SNMP agents have much less than that, so I don't
think this is an issue at all.

>Even TLS (usually) doesn't do DH key exchange.

I mean DH key ex, not DH certificate (which is for auth). =20
SSL/TLS suites have two options for key exchange: DH and RSA. =20
I am not sure which one is used more frequently, but some sources=20
say DH is more secure.=20

http://www.scramdisk.clara.net/pgpfaq.html#SubRSADH=20

Anyway, I cited DH as an example, but RSA key exchange can be used too.

I don't think they are much different in term of computing resource.

>=20
> > If it's (2), then maybe we first need to decide which 'abstract'
> > authentication method to be used, before going to the=20
> specific keying=20
> > scheme implementation (some auth method may not need any
> 'key'):
>=20
> Very nice - except that the contestants are about equally=20
> divided between these: some need Kerberos, some need PKI,=20
> some insist that
> *their* "constituency" can deal efficiently only with SSH.=20
> And it's not a big deal to make a code stew to support all of=20
> the above and below - except that it's next to impossible to=20
> analyse security property of the resulting stew. Not that=20
> everybody cares, of course...

That's why I proposed a single authentication method independent
with underlying transport (connectionless, TCP, TLS):  The
Localized PSK (LPSK) method.  I borrow your idea (USM localized=20
Keys) and extend it in conjuction w/ a PSK method such as SRP
to auth snmp entities (I mean at session/connection level, not MAC)

Best Regards.

Khanh

>=20
> + kerberos authentication
> + public-key certificate (e.g. x509)
> + pre-shared key (PSK) auth
> + centralized AAA (e.g. radius)
> + password digest (user auth only)
> + host key files (SSH host auth)
> + etc...
>=20
> Khanh
>=20
> > -----Original Message-----
> > From: isms-bounces@lists.ietf.org
> > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein
> > Sent: Thursday, April 21, 2005 1:18 PM
> > To: isms@ietf.org
> > Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> >=20
> > ISMS members,
> >=20
> > There's been a lot of discussion recently on the mailing list about=20
> > the pros and cons of different security models.  I think the=20
> > discussion has been good, but unfortunately I don't think=20
> it's getting=20
> > any closer to a consensus (I thank Robert for trying to draw things=20
> > closer; unfortunately Juergen and I have been rather busy off-line,=20
> > and I apologize for that).  I know that some on the mailing=20
> list have=20
> > expressed a preference for choosing a security protocol first, but=20
> > we've been tasked with choosing the architecture first, and=20
> I believe=20
> > that is the appropriate approach.
> >=20
> > Anyway, I'd like to call for a consensus on the security=20
> architecture.
> > As we all know, the three choices are:
> >=20
> > - Out of band keying (the architecture used by EUSM)
> > - In-bakd keying (the architecture used by SBSM)
> > - Encapsulation keying (the architecture used by TLSM)
> >=20
> > What I would like to see is WG members express which
> > architecture(s) they prefer (you can choose more than one,=20
> but please,=20
> > don't choose all three).  Please feel free to state your=20
> reasons for=20
> > your choices, but in the interests of reaching consensus in a=20
> > reasonable timeframe, I am asking that WG members please=20
> refrain from=20
> > commenting on other people's choices unless they feel that=20
> the person=20
> > has stated a fact which is obviously wrong.
> >=20
> > Thanks for your time,
> >=20
> > --Ken
> >=20
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> >=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 07:49:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOwf4-0008Qt-Rb; Fri, 22 Apr 2005 07:49:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwf3-0008Qo-0H
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 07:49:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08997
	for <isms@ietf.org>; Fri, 22 Apr 2005 07:49:27 -0400 (EDT)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251]
	helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DOwqe-0000Df-8Z
	for isms@ietf.org; Fri, 22 Apr 2005 08:01:29 -0400
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0031EA;
	22 Apr 2005 07:48:53 -0400
Received: from spooler by Lamicro.com (Mercury/32 v4.01b);
	22 Apr 2005 07:48:36 -0400
Received: from connotech.com (209.71.204.122) by SMTP.Lamicro.com (Mercury/32
	v4.01b) with ESMTP ID MG0031E9; 22 Apr 2005 07:48:26 -0400
Message-ID: <4268EB2B.7050808@connotech.com>
Date: Fri, 22 Apr 2005 08:16:43 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
References: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>
	<Pine.LNX.4.56.0504212145530.4057@internaut.com>
In-Reply-To: <Pine.LNX.4.56.0504212145530.4057@internaut.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: radiusext@ops.ietf.org, isms@ietf.org, eap@frascone.com
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Dear all:

Is it concievable to design end-to-end security (i.e. from NAS to RADIUS 
server through any intermediate RADIUS proxies) with an 
implementation-specific attribute to the RADIUS Access-Accept packet? 
This requires a pre-shared secret key between the RADIUS server (or more 
precisely an implementation-specific server co-located with the RADIUS 
server) and the application-specific component co-located with the 
RADIUS NAS.

This is part of a proposal ("A session-less fix to SNMP security 
issues?", 
http://www1.ietf.org/mail-archive/web/isms/current/msg00527.html) to the 
isms audience.

The security implication of RADIUS proxies has been noticed in isms 
mailing list early on. Perhaps it has been overlooked at some point in 
the discussion.

Regards,


- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


Bernard Aboba wrote:
>>Yet NAS takes "go/no-go" decision from RADIUS, and takes the keys to
>>talk to the client... If this is not trust - what is it?
> 
> 
> There is no IETF standard defining how keys are provided within
> RADIUS for exactly that reason -- there is no trust relationship defined
> when a proxy is present.  The "Housley Criteria" described in RFC 4017 do
> not allow disclosure of keys to additional parties.
> 
> The problem does not exist in Diameter EAP, which enables keys to
> be provided directly without access by proxies.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 10:35:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOzFt-0004FP-TK; Fri, 22 Apr 2005 10:35:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOzFs-0004FG-UE
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 10:35:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23879
	for <isms@ietf.org>; Fri, 22 Apr 2005 10:35:38 -0400 (EDT)
Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOzRW-0004FI-Jh
	for isms@ietf.org; Fri, 22 Apr 2005 10:47:43 -0400
Received: (from uucp@localhost)
	by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA17806
	for <isms@ietf.org>; Fri, 22 Apr 2005 10:36:41 -0400 (EDT)
Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap
	(4.1) id xma017158; Fri, 22 Apr 05 10:34:11 -0400
Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by
	134.141.79.124 with InterScan Messaging Security Suite;
	Fri, 22 Apr 2005 10:33:05 -0400
Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; 
	Fri, 22 Apr 2005 10:33:05 -0400
Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with
	Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Apr 2005 10:33:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Fri, 22 Apr 2005 10:33:02 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322DC@MAANDMBX2.ets.enterasys.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVGoE72do1f9de2Q8WQrAZhTXLhGgApmOJg
From: "Nelson, David" <dnelson@enterasys.com>
To: "John Vollbrecht" <jrv@umich.edu>
X-OriginalArrivalTime: 22 Apr 2005 14:33:05.0342 (UTC)
	FILETIME=[321595E0:01C54748]
X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8
X-pstn-levels: (C:90.6772 M:94.5022 P:95.9108 R:95.9108 S:41.0858 )
X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13
X-pstn-addresses: from <dnelson@enterasys.com> forward (org good) 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org


John Vollbrecht writes ... [mailto:jrv@umich.edu]
> The question I am wondering about is whether the RADIUS server could
be
> a trusted third party if it is directly connected to the NAS.  In that
> case it has credentials with all parties.  However the credentials are
> of quite different form - I am wondering if the form of credentials or
> the relationship between the credentials makes a difference in whether
> it can act effectively as a trusted third party.  My first guess  is
> that it could (especially if RADIUS had stronger hashing) but I am not
> sure.
> What is your thought?

I suspect there are cases in which a single (non-proxy) RADIUS server
could act as a trusted third party, but that would depend on the extent
to which the RADIUS server and the EAP server were considered a single
entity.  I think the issue is whether all parties can [directly]
validate the bindings of authenticated identity to keys. When one set of
bindings is created via the EAP session between the EAP peer and EAP
server and another set of bindings is created via the RADIUS
authentication and authorization exchanges between the RADIUS server and
the NAS, there is certainly the opportunity for the parties to have
disjoint sets of key bindings.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 10:53:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DOzWk-0006iX-EE; Fri, 22 Apr 2005 10:53:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOzWj-0006iS-IX
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 10:53:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25144
	for <isms@ietf.org>; Fri, 22 Apr 2005 10:53:03 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOziL-0004gA-Ph
	for isms@ietf.org; Fri, 22 Apr 2005 11:05:08 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DOzWe-0004Ak-E7; Fri, 22 Apr 2005 10:53:00 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3MEqwW09718;
	Fri, 22 Apr 2005 07:52:58 -0700
Date: Fri, 22 Apr 2005 07:52:58 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Thierry Moreau <thierry.moreau@connotech.com>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <4268EB2B.7050808@connotech.com>
Message-ID: <Pine.LNX.4.56.0504220731040.6961@internaut.com>
References: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>
	<Pine.LNX.4.56.0504212145530.4057@internaut.com>
	<4268EB2B.7050808@connotech.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: radiusext@ops.ietf.org, isms@ietf.org, eap@frascone.com
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> Is it concievable to design end-to-end security (i.e. from NAS to RADIUS
> server through any intermediate RADIUS proxies) with an
> implementation-specific attribute to the RADIUS Access-Accept packet?

Diameter CMS enabled the creation of attributes that could be sent between
the RADIUS server and NAS without being revealed to an intermediate proxy.
Therefore it could be said that it enabled "end-to-end" trust, something
that was already possible within Diameter in other ways (re-direct).
Since re-direct needed to be supported anyway and also solved the
problem, that was the direction that was taken once it became clear
that there was not enough interest in Diameter CMS to continue the
work.

Note that Re-direct-based trust is built on the following elements:

    1. Support for DNS discovery of RADIUS servers within a domain.
       This allows the RADIUS client to discover which RADIUS server
       it needs to talk to.

    2. Support for certificate-based authentication.  For inter-domain
       purposes, this is handled via TLS within Diameter.  This
       allows a Diameter client to contact an arbitrary Diameter server
       and mutually authenticate to it, provided that the certificate
       chain can be validated.  With TLS it is possible to create
       application-specific trust chains, something that is much more
       difficult within IKE, so that the trust anchor for Diameter
       (e.g. certificates signed by a roaming consortium CA) need
       not be the same as for other applications (e.g. Verisign
       certificate for a Web server).

It is conceivable to add support for both of these elements to RADIUS, but
of these, element #2 is more difficult. RADIUS over IPsec is defined in
RFC 3579, but it is not deployed for inter-domain usage. To address the
limitations, RADIUS over TLS (RADSEC) has now been defined and is shipping.
My understanding is that it is being considered for deployment within large
inter-continental roaming networks (e.g. TERENA).  More info on RADSEC is
available here:

http://www.terena.nl/mail-archives/mobility/msg01225.html
http://www.open.com.au/radiator/radsec-whitepaper.pdf

> This requires a pre-shared secret key between the RADIUS server (or more
> precisely an implementation-specific server co-located with the RADIUS
> server) and the application-specific component co-located with the
> RADIUS NAS.

Are you proposing creating a new RADIUS security model that would only be
used by ISMS?  That seems like a lot of work for little overall benefit
to the RADIUS community.

> The security implication of RADIUS proxies has been noticed in isms
> mailing list early on. Perhaps it has been overlooked at some point in
> the discussion.

Rather than designing a new version of RADIUS to meet its needs, it seems
more profitable for ISMS to either figure out how to use the protocol as
it exists today, or to summarize its requirements for new work and ask
that it be chartered outside of ISMS.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 11:25:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP01o-000248-0w; Fri, 22 Apr 2005 11:25:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP01m-00022R-FO
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 11:25:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27446
	for <isms@ietf.org>; Fri, 22 Apr 2005 11:25:08 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP0DQ-0005Q6-1K
	for isms@ietf.org; Fri, 22 Apr 2005 11:37:13 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DP01j-0009Pa-0k; Fri, 22 Apr 2005 11:25:07 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3MFP5L11675;
	Fri, 22 Apr 2005 08:25:05 -0700
Date: Fri, 22 Apr 2005 08:25:05 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Julien Bournelle <julien.bournelle@int-evry.fr>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <20050422144549.GD18053@ipv6-3.int-evry.fr>
Message-ID: <Pine.LNX.4.56.0504220759430.6961@internaut.com>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com>
	<Pine.LNX.4.56.0504211947310.28498@internaut.com>
	<20050422144549.GD18053@ipv6-3.int-evry.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>  I'm wondering if an operator will let its EAP authenticator directly
>  contact EAP server from other operators using redirect functionality of
>  Diameter.

As I understand it, proxy bypass is being considered by TERENA primarily
to eliminate excessive latency in trans-continental roaming.  More info on
the "trust fabric" of EduRoam NG is available here:

http://www.terena.nl/tech/task-forces/tf-mobility/
http://www.eduroam.org/docs/eduroam-article.pdf
http://www.eduroam.org/wiki/NextGeneration?v=ina
http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf
http://www.es.net/raf/ESnet-RAF-WP.html

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 13:29:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP1yJ-0002ee-TG; Fri, 22 Apr 2005 13:29:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP1yH-0002eZ-Uv
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 13:29:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06369
	for <isms@ietf.org>; Fri, 22 Apr 2005 13:29:37 -0400 (EDT)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251]
	helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP29u-0008QP-89
	for isms@ietf.org; Fri, 22 Apr 2005 13:41:44 -0400
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO003533;
	22 Apr 2005 13:29:03 -0400
Received: from spooler by Lamicro.com (Mercury/32 v4.01b);
	22 Apr 2005 13:28:17 -0400
Received: from connotech.com (209.71.204.122) by SMTP.Lamicro.com (Mercury/32
	v4.01b) with ESMTP ID MG003532; 22 Apr 2005 13:28:13 -0400
Message-ID: <42693ACC.80603@connotech.com>
Date: Fri, 22 Apr 2005 13:56:28 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
References: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>
	<Pine.LNX.4.56.0504212145530.4057@internaut.com>
	<4268EB2B.7050808@connotech.com>
	<Pine.LNX.4.56.0504220731040.6961@internaut.com>
In-Reply-To: <Pine.LNX.4.56.0504220731040.6961@internaut.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: radiusext@ops.ietf.org, isms@ietf.org, eap@frascone.com
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Thanks for these explanations.

See comments in-line below.



Bernard Aboba wrote:

[... explanations about end-to-end (NAS to server) and current RADIUS 
protocols ...]

> 
> Are you proposing creating a new RADIUS security model that would only be
> used by ISMS?  That seems like a lot of work for little overall benefit
> to the RADIUS community.
> 

I did assume that an implementation-specific attribute to the RADIUS 
Access-Accept packet would pass unmodified through a RADIUS proxy, which 
in fact is a matter of proxy policy (RFC2865 , section 2.3). With this 
erroneous assumption, I thought I was proposing an 
implementation-specific use of existing RADIUS protocol facility. I did 
not expect any "benefit to the RADIUS community".

> 
> 
> Rather than designing a new version of RADIUS to meet its needs, it seems
> more profitable for ISMS to either figure out how to use the protocol as
> it exists today, or to summarize its requirements for new work and ask
> that it be chartered outside of ISMS.
> 

Point well taken. I just looked at RFC3576, abstract reproduced below

    "This document describes a currently deployed extension to the Remote
    Authentication Dial In User Service (RADIUS) protocol, allowing
    dynamic changes to a user session, as implemented by network access
    server products.  This includes support for disconnecting users and
    changing authorizations applicable to a user session."

Unfortunately, the security section of RFC3576 raises a number of 
concerns. E.g. the following sentence: "It is RECOMMENDED that IPsec be 
employed to afford better security."

Again, thanks for your comments.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 15:03:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP3RV-0004co-Va; Fri, 22 Apr 2005 15:03:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP3RU-0004Zs-P9
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 15:03:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12539
	for <isms@ietf.org>; Fri, 22 Apr 2005 15:03:55 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP3dA-00023S-Cq
	for isms@ietf.org; Fri, 22 Apr 2005 15:16:01 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3MJ3nLP015516
	for <isms@ietf.org>; Fri, 22 Apr 2005 15:03:50 -0400 (EDT)
Message-Id: <200504221903.j3MJ3nLP015516@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture 
In-Reply-To: <BC5CFB047387BD41AC606027302F1FDD13F919@xmb-sjc-22e.amer.cisco.com>
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Fri, 22 Apr 2005 15:03:49 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>Sorry if I missed something, but when discussing about the keying
>choices, are we talking about (1) encryption keys or (2) authentication keys? 

In general, we're talking about (1) encryption keys.  Actually, I don't
necessarily like to think about "keys" at this stage.  If we're doing
something like EK, then SNMP doesn't really know about keys at all.

>If it's (2), then maybe we first need to decide which 'abstract'
>authentication method to be used, before going to the specific 
>keying scheme implementation (some auth method may not need any 'key'):
>[...]

The issue is that most of the systems you list generally don't want
application protocols to know about their keys; they want applications
to treat the authentication exchange as a "black box".  When dealing
with different authentication schemes, the protocols I've seen that
handle this the best provide a framework that different authentication
schemes can plug into.  SASL is an example of this (I'm not saying it's
appropriate for SNMP, but it's an example of a good framework that
handles different authentication mechanisms).

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 15:24:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP3l9-0006oO-NB; Fri, 22 Apr 2005 15:24:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP3l7-0006oJ-Lw
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 15:24:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14773
	for <isms@ietf.org>; Fri, 22 Apr 2005 15:24:11 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP3wm-0002Te-TG
	for isms@ietf.org; Fri, 22 Apr 2005 15:36:18 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3MJNkUU011016; 
	Fri, 22 Apr 2005 19:23:46 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3MJNMUj022555; 
	Fri, 22 Apr 2005 19:23:46 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042212234605331 ; Fri, 22 Apr 2005 12:23:46 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 22 Apr 2005 12:23:46 -0700
Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 22 Apr 2005 12:23:44 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 22 Apr 2005 15:23:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture 
Date: Fri, 22 Apr 2005 15:23:18 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290107B685@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture 
Thread-Index: AcVHbiRRzHZrvWfDRBiEv9tKs9YIHwAAgNXg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>, <isms@ietf.org>
X-OriginalArrivalTime: 22 Apr 2005 19:23:43.0788 (UTC)
	FILETIME=[CC3546C0:01C54770]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>Sorry if I missed something, but when discussing about the keying
>>choices, are we talking about (1) encryption keys or (2)
authentication keys?=20
>
>In general, we're talking about (1) encryption keys.  Actually, I don't
>necessarily like to think about "keys" at this stage.  If we're doing
>something like EK, then SNMP doesn't really know about keys at all.

What??? "Keys" is only practical outcome of a successful authentication
process. Otherwise the procedure is meaningless. Leaving alone the "EK"
and its meaning.

>>If it's (2), then maybe we first need to decide which 'abstract'
>>authentication method to be used, before going to the specific=20
>>keying scheme implementation (some auth method may not need any
'key'):
>
>The issue is that most of the systems you list generally don't want
>application protocols to know about their keys; they want applications
                                     ^^^^^
>to treat the authentication exchange as a "black box".

In general the idea is that this "black box" performs its magic,
pronounces the authentication decision and handles down the keys for the
duration of the conversation.=20

Some of those "black boxes" also want to carry the messages between the
parties by themselves.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 15:26:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP3nS-0006yb-VY; Fri, 22 Apr 2005 15:26:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP3nR-0006yQ-HW
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 15:26:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14906
	for <isms@ietf.org>; Fri, 22 Apr 2005 15:26:35 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP3z7-0002WZ-9u
	for isms@ietf.org; Fri, 22 Apr 2005 15:38:42 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3MJQTii016031
	for <isms@ietf.org>; Fri, 22 Apr 2005 15:26:30 -0400 (EDT)
Message-Id: <200504221926.j3MJQTii016031@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture 
In-Reply-To: <3DEC199BD7489643817ECA151F7C59290107B685@pysmsx401.amr.corp.intel.com>
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Fri, 22 Apr 2005 15:26:29 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>In general, we're talking about (1) encryption keys.  Actually, I don't
>>necessarily like to think about "keys" at this stage.  If we're doing
>>something like EK, then SNMP doesn't really know about keys at all.
>
>What??? "Keys" is only practical outcome of a successful authentication
>process. Otherwise the procedure is meaningless. Leaving alone the "EK"
>and its meaning.

I was actually specifically thinking of EK when I wrote this.  Normally,
yes, I agree with you.

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 22 17:41:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DP5tc-0002Xo-VZ; Fri, 22 Apr 2005 17:41:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5tb-0002Xf-Or
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 17:41:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05255
	for <isms@ietf.org>; Fri, 22 Apr 2005 17:41:05 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DP65I-00017s-ND
	for isms@ietf.org; Fri, 22 Apr 2005 17:53:14 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 22 Apr 2005 14:28:28 -0700
X-IronPort-AV: i="3.92,125,1112598000"; 
	d="scan'208"; a="253551120:sNHT1491006828"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3MLRZiO020307;
	Fri, 22 Apr 2005 14:28:25 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 22 Apr 2005 14:27:58 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture 
Date: Fri, 22 Apr 2005 14:28:23 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13F949@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture 
Thread-Index: AcVHbh/J5G8tPWcFTh+Iq5Sqtkn8SgAEAomQ
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>, <isms@ietf.org>
X-OriginalArrivalTime: 22 Apr 2005 21:27:58.0550 (UTC)
	FILETIME=[2797AF60:01C54782]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> -----Original Message-----
> From: Ken Hornstein
>=20
> In general, we're talking about (1) encryption keys. =20
> Actually, I don't necessarily like to think about "keys" at=20
> this stage.  If we're doing something like EK, then SNMP=20
> doesn't really know about keys at all.

I completely agree.  As Kausick earlier pointed out, the primary
issue that need to be decided first is whether to do the=20
security services at (a) transport layer or (b) application=20
(SNMP) layer.  Another primary issue is what type(s) of transport=20
to use: sessionless (e.g. USM), session-oriented (e.g. EUSM/SBSM)=20
or connection-oriented (e.g. TLSM).  Once we can agree on these=20
issues, it'll be easier to talk about keying mechanism.
W/out a common base, the discussion could be very confusing.

Khanh

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 25 08:57:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQ39i-0006SS-Kt; Mon, 25 Apr 2005 08:57:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ39Q-0006R3-SY
	for isms@megatron.ietf.org; Mon, 25 Apr 2005 08:57:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12902
	for <isms@ietf.org>; Mon, 25 Apr 2005 08:57:12 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ3LU-00088F-MG
	for isms@ietf.org; Mon, 25 Apr 2005 09:09:54 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3PCuxn13070; Mon, 25 Apr 2005 08:56:59 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3PCv9s25490; Mon, 25 Apr 2005 08:57:09 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3R3DZ4>; Mon, 25 Apr 2005 08:56:58 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9BBA@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Thierry Moreau'" <thierry.moreau@connotech.com>, Bernard Aboba
	<aboba@internaut.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Mon, 25 Apr 2005 08:56:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0939806407=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0939806407==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54996.391F6668"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54996.391F6668
Content-Type: text/plain

The use of RADIUS itself without a defined extension such as EAP-TLS or
EAP-PEAP over RADIUS cannot securely pass attributes between entities. Note
that the defined EAP-TLS (or other EAP mechanisms) over RADIUS provides for
secure attribute passing between entities even through proxies.

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Thierry Moreau
> Sent: April 22, 2005 1:56 PM
> To: Bernard Aboba
> Cc: radiusext@ops.ietf.org; isms@ietf.org; eap@frascone.com
> Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> 
> Thanks for these explanations.
> 
> See comments in-line below.
> 
> 
> 
> Bernard Aboba wrote:
> 
> [... explanations about end-to-end (NAS to server) and current RADIUS 
> protocols ...]
> 
> > 
> > Are you proposing creating a new RADIUS security model that 
> would only 
> > be used by ISMS?  That seems like a lot of work for little overall 
> > benefit to the RADIUS community.
> > 
> 
> I did assume that an implementation-specific attribute to the RADIUS 
> Access-Accept packet would pass unmodified through a RADIUS 
> proxy, which 
> in fact is a matter of proxy policy (RFC2865 , section 2.3). 
> With this 
> erroneous assumption, I thought I was proposing an 
> implementation-specific use of existing RADIUS protocol 
> facility. I did 
> not expect any "benefit to the RADIUS community".
> 
> > 
> > 
> > Rather than designing a new version of RADIUS to meet its needs, it 
> > seems more profitable for ISMS to either figure out how to use the 
> > protocol as it exists today, or to summarize its 
> requirements for new 
> > work and ask that it be chartered outside of ISMS.
> > 
> 
> Point well taken. I just looked at RFC3576, abstract reproduced below
> 
>     "This document describes a currently deployed extension 
> to the Remote
>     Authentication Dial In User Service (RADIUS) protocol, allowing
>     dynamic changes to a user session, as implemented by 
> network access
>     server products.  This includes support for disconnecting 
> users and
>     changing authorizations applicable to a user session."
> 
> Unfortunately, the security section of RFC3576 raises a number of 
> concerns. E.g. the following sentence: "It is RECOMMENDED 
> that IPsec be 
> employed to afford better security."
> 
> Again, thanks for your comments.
> 
> -- 
> 
> - Thierry Moreau
> 
> CONNOTECH Experts-conseils inc.
> 9130 Place de Montgolfier
> Montreal, Qc
> Canada   H2M 2A1
> 
> Tel.: (514)385-5691
> Fax:  (514)385-5900
> 
> web site: http://www.connotech.com
> e-mail: thierry.moreau@connotech.com
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

------_=_NextPart_001_01C54996.391F6668
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third party</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The use of RADIUS itself without a defined extension =
such as EAP-TLS or EAP-PEAP over RADIUS cannot securely pass attributes =
between entities. Note that the defined EAP-TLS (or other EAP =
mechanisms) over RADIUS provides for secure attribute passing between =
entities even through proxies.</FONT></P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Thierry Moreau</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 22, 2005 1:56 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Bernard Aboba</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: radiusext@ops.ietf.org; isms@ietf.org; =
eap@frascone.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [eap] RE: [Isms] RADIUS is not a =
trusted third party</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks for these explanations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; See comments in-line below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bernard Aboba wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [... explanations about end-to-end (NAS to =
server) and current RADIUS </FONT>
<BR><FONT SIZE=3D2>&gt; protocols ...]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Are you proposing creating a new RADIUS =
security model that </FONT>
<BR><FONT SIZE=3D2>&gt; would only </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be used by ISMS?&nbsp; That seems like a =
lot of work for little overall </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; benefit to the RADIUS community.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I did assume that an implementation-specific =
attribute to the RADIUS </FONT>
<BR><FONT SIZE=3D2>&gt; Access-Accept packet would pass unmodified =
through a RADIUS </FONT>
<BR><FONT SIZE=3D2>&gt; proxy, which </FONT>
<BR><FONT SIZE=3D2>&gt; in fact is a matter of proxy policy (RFC2865 , =
section 2.3). </FONT>
<BR><FONT SIZE=3D2>&gt; With this </FONT>
<BR><FONT SIZE=3D2>&gt; erroneous assumption, I thought I was proposing =
an </FONT>
<BR><FONT SIZE=3D2>&gt; implementation-specific use of existing RADIUS =
protocol </FONT>
<BR><FONT SIZE=3D2>&gt; facility. I did </FONT>
<BR><FONT SIZE=3D2>&gt; not expect any &quot;benefit to the RADIUS =
community&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Rather than designing a new version of =
RADIUS to meet its needs, it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; seems more profitable for ISMS to either =
figure out how to use the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocol as it exists today, or to =
summarize its </FONT>
<BR><FONT SIZE=3D2>&gt; requirements for new </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; work and ask that it be chartered outside =
of ISMS.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Point well taken. I just looked at RFC3576, =
abstract reproduced below</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This document =
describes a currently deployed extension </FONT>
<BR><FONT SIZE=3D2>&gt; to the Remote</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Authentication Dial In =
User Service (RADIUS) protocol, allowing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; dynamic changes to a =
user session, as implemented by </FONT>
<BR><FONT SIZE=3D2>&gt; network access</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; server products.&nbsp; =
This includes support for disconnecting </FONT>
<BR><FONT SIZE=3D2>&gt; users and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; changing authorizations =
applicable to a user session.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Unfortunately, the security section of RFC3576 =
raises a number of </FONT>
<BR><FONT SIZE=3D2>&gt; concerns. E.g. the following sentence: &quot;It =
is RECOMMENDED </FONT>
<BR><FONT SIZE=3D2>&gt; that IPsec be </FONT>
<BR><FONT SIZE=3D2>&gt; employed to afford better =
security.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Again, thanks for your comments.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - Thierry Moreau</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; CONNOTECH Experts-conseils inc.</FONT>
<BR><FONT SIZE=3D2>&gt; 9130 Place de Montgolfier</FONT>
<BR><FONT SIZE=3D2>&gt; Montreal, Qc</FONT>
<BR><FONT SIZE=3D2>&gt; Canada&nbsp;&nbsp; H2M 2A1</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tel.: (514)385-5691</FONT>
<BR><FONT SIZE=3D2>&gt; Fax:&nbsp; (514)385-5900</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; web site: <A HREF=3D"http://www.connotech.com" =
TARGET=3D"_blank">http://www.connotech.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; e-mail: thierry.moreau@connotech.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54996.391F6668--


--===============0939806407==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0939806407==--




From isms-bounces@lists.ietf.org Mon Apr 25 09:34:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQ3jJ-0001IZ-7L; Mon, 25 Apr 2005 09:34:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DOzRo-0005n0-Kn
	for isms@megatron.ietf.org; Fri, 22 Apr 2005 10:48:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24630
	for <isms@ietf.org>; Fri, 22 Apr 2005 10:47:58 -0400 (EDT)
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOzdS-0004Wk-8h
	for isms@ietf.org; Fri, 22 Apr 2005 11:00:02 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 066168037;
	Fri, 22 Apr 2005 16:47:42 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.50)
	id 1DOzPh-0004ki-UA; Fri, 22 Apr 2005 16:45:49 +0200
Date: Fri, 22 Apr 2005 16:45:49 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
Message-ID: <20050422144549.GD18053@ipv6-3.int-evry.fr>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com>
	<Pine.LNX.4.56.0504211947310.28498@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.56.0504211947310.28498@internaut.com>
User-Agent: Mutt/1.5.6+20040907i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
X-Mailman-Approved-At: Mon, 25 Apr 2005 09:34:27 -0400
Cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi,

On Thu, Apr 21, 2005 at 07:59:46PM -0700, Bernard Aboba wrote:
> > I think there is a subtle difference between a "trusted third party" and
> > a RADIUS server which may have bi-lateral trust relationships with
> > various parties.
> 
> Yes.  Where RADIUS proxies are present there is no trust relationship
> between the NAS and RADIUS server.  This is in contrast to Diameter, where
> such a relationship can be established via re-direct.

 I'm wondering if an operator will let its EAP authenticator directly
 contact EAP server from other operators using redirect functionality of
 Diameter. 
 
 regards,


> 
> The distinction is important in a number of cases.  In Kerberos, the KDC
> is able to provide a ticket to any principal because it has a shared
> secret that it shares with that principle.
> 
> Within RADIUS this is not possible.  A RADIUS server cannot
> provide the user with a ticket to a NAS because it may not have a trust
> relationship with that NAS.
> 
> Note that at one point, there was a proposal for integration of RADIUS
> with Kerberos.  That proposal did in fact enable RADIUS to become a true
> trusted third party.  The proposal seemed practical. However, the AAA WG
> went with another proposal (Diameter CMS) which it turned out that noone
> wanted to implement. Among other things, the proposal enabled a RADIUS
> server to send a key to a NAS that could not be viewed by intervening
> proxies.  In retrospect, the IETF may have missed an important
> opportunity.
> 
> For a trip down memory lane, look here:
> http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt
> 
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap

-- 
julien.bournelle at int-evry.fr

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 25 12:00:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQ60Z-0007cn-3F; Mon, 25 Apr 2005 12:00:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ60X-0007c4-G0
	for isms@megatron.ietf.org; Mon, 25 Apr 2005 12:00:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27456
	for <isms@ietf.org>; Mon, 25 Apr 2005 12:00:22 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ6Cm-0006Le-8u
	for isms@ietf.org; Mon, 25 Apr 2005 12:13:05 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DQ60S-000FmE-QZ; Mon, 25 Apr 2005 12:00:20 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3PG0I124477;
	Mon, 25 Apr 2005 09:00:18 -0700
Date: Mon, 25 Apr 2005 09:00:18 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Martin Soukup <msoukup@nortel.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9BBA@zcarhxm2.corp.nortel.com>
Message-ID: <Pine.LNX.4.56.0504250858030.21845@internaut.com>
References: <0BDFFF51DC89434FA33F8B37FCE363D5030B9BBA@zcarhxm2.corp.nortel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> The use of RADIUS itself without a defined extension such as EAP-TLS or
> EAP-PEAP over RADIUS cannot securely pass attributes between entities. Note
> that the defined EAP-TLS (or other EAP mechanisms) over RADIUS provides for
> secure attribute passing between entities even through proxies.

EAP does not affect how RADIUS attributes are passed, nor does it enable
the passing of RADIUS attributes between the EAP peer and server.  So as
far as RADIUS attributes are concerned, what EAP method is used, or
whether EAP is used does not affect RADIUS security, except that an
EAP-Message attribute is included in the messages.

Also, EAP-TLS does not permit passing of TLVs between the peer and server;
this is only allowed in tunneled mechanisms such as EAP-TTLS and PEAP.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Mon Apr 25 13:29:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQ7Oa-0007RB-6T; Mon, 25 Apr 2005 13:29:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ7OY-0007R6-3w
	for isms@megatron.ietf.org; Mon, 25 Apr 2005 13:29:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03762
	for <isms@ietf.org>; Mon, 25 Apr 2005 13:29:14 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ7ap-0000vh-Jt
	for isms@ietf.org; Mon, 25 Apr 2005 13:42:00 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 25 Apr 2005 19:29:08 +0200
Received: from gwzw2k01 (rtp-vpn2-904.cisco.com [10.82.243.136])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3PHT254017150; 
	Mon, 25 Apr 2005 19:29:03 +0200 (MEST)
Message-Id: <200504251729.j3PHT254017150@ams-core-1.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Martin Soukup'" <msoukup@nortel.com>,
	"'Thierry Moreau'" <thierry.moreau@connotech.com>,
	"'Bernard Aboba'" <aboba@internaut.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Mon, 25 Apr 2005 10:28:56 -0700
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5030B9BBA@zcarhxm2.corp.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVJlvONKqR4Qo7bQGet8WrhlnyAXQAJFy3g
X-Spam-Score: 0.9 (/)
X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1202129815=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1202129815==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0087_01C54981.9B1F8470"

This is a multi-part message in MIME format.

------=_NextPart_000_0087_01C54981.9B1F8470
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The use of RADIUS itself without a defined extension such as EAP-TLS
or EAP-PEAP over RADIUS cannot securely pass attributes between
entities. Note that the defined EAP-TLS (or other EAP mechanisms)
over RADIUS provides for secure attribute passing between entities
even through proxies. 
 
I thought that I was passing familiar w/EAP-TLS (and even more so
w/PEAP), but I am completely unaware of such capabilities.  Would
you mind explaining how this is achieved, given that RADIUS & EAP
are completely different protocols?

Martin. 

> -----Original Message----- 
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Thierry Moreau 
> Sent: April 22, 2005 1:56 PM 
> To: Bernard Aboba 
> Cc: radiusext@ops.ietf.org; isms@ietf.org; eap@frascone.com 
> Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party 
> 
> 
> Thanks for these explanations. 
> 
> See comments in-line below. 
> 
> 
> 
> Bernard Aboba wrote: 
> 
> [... explanations about end-to-end (NAS to server) and current
RADIUS 
> protocols ...] 
> 
> > 
> > Are you proposing creating a new RADIUS security model that 
> would only 
> > be used by ISMS?  That seems like a lot of work for little
overall 
> > benefit to the RADIUS community. 
> > 
> 
> I did assume that an implementation-specific attribute to the
RADIUS 
> Access-Accept packet would pass unmodified through a RADIUS 
> proxy, which 
> in fact is a matter of proxy policy (RFC2865 , section 2.3). 
> With this 
> erroneous assumption, I thought I was proposing an 
> implementation-specific use of existing RADIUS protocol 
> facility. I did 
> not expect any "benefit to the RADIUS community". 
> 
> > 
> > 
> > Rather than designing a new version of RADIUS to meet its needs,
it 
> > seems more profitable for ISMS to either figure out how to use
the 
> > protocol as it exists today, or to summarize its 
> requirements for new 
> > work and ask that it be chartered outside of ISMS. 
> > 
> 
> Point well taken. I just looked at RFC3576, abstract reproduced
below 
> 
>     "This document describes a currently deployed extension 
> to the Remote 
>     Authentication Dial In User Service (RADIUS) protocol,
allowing 
>     dynamic changes to a user session, as implemented by 
> network access 
>     server products.  This includes support for disconnecting 
> users and 
>     changing authorizations applicable to a user session." 
> 
> Unfortunately, the security section of RFC3576 raises a number of 
> concerns. E.g. the following sentence: "It is RECOMMENDED 
> that IPsec be 
> employed to afford better security." 
> 
> Again, thanks for your comments. 
> 
> -- 
> 
> - Thierry Moreau 
> 
> CONNOTECH Experts-conseils inc. 
> 9130 Place de Montgolfier 
> Montreal, Qc 
> Canada   H2M 2A1 
> 
> Tel.: (514)385-5691 
> Fax:  (514)385-5900 
> 
> web site: http://www.connotech.com 
> e-mail: thierry.moreau@connotech.com 
> 
> 
> _______________________________________________ 
> Isms mailing list 
> Isms@lists.ietf.org 
> https://www1.ietf.org/mailman/listinfo/isms 
> 
> 


------=_NextPart_000_0087_01C54981.9B1F8470
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third =
party</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1498" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2>The use of RADIUS itself =
without a defined=20
extension such as EAP-TLS or EAP-PEAP over RADIUS cannot securely pass=20
attributes between entities. Note that the defined EAP-TLS (or other EAP =

mechanisms) over RADIUS provides for secure attribute passing between =
entities=20
even through proxies.<SPAN class=3D408102217-25042005><FONT face=3DArial =

color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
class=3D408102217-25042005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D408102217-25042005><FONT=20
face=3DArial color=3D#0000ff>I thought that I was passing familiar =
w/EAP-TLS (and=20
even more so w/PEAP), but I am completely unaware of such =
capabilities.&nbsp;=20
Would you mind explaining how this is achieved, given that RADIUS &amp; =
EAP are=20
completely different protocols?</FONT></SPAN></FONT></DIV>
<P><FONT size=3D2>Martin.</FONT> </P>
<P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
From: isms-bounces@lists.ietf.org </FONT><BR><FONT size=3D2>&gt; [<A=20
href=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.iet=
f.org</A>]=20
On Behalf Of Thierry Moreau</FONT> <BR><FONT size=3D2>&gt; Sent: April =
22, 2005=20
1:56 PM</FONT> <BR><FONT size=3D2>&gt; To: Bernard Aboba</FONT> =
<BR><FONT=20
size=3D2>&gt; Cc: radiusext@ops.ietf.org; isms@ietf.org; =
eap@frascone.com</FONT>=20
<BR><FONT size=3D2>&gt; Subject: Re: [eap] RE: [Isms] RADIUS is not a =
trusted=20
third party</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Thanks for these explanations.</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; See comments in-line =
below.</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Bernard Aboba wrote:</FONT> <BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; [... explanations about end-to-end (NAS =
to server)=20
and current RADIUS </FONT><BR><FONT size=3D2>&gt; protocols ...]</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
Are you proposing creating a new RADIUS security model that =
</FONT><BR><FONT=20
size=3D2>&gt; would only </FONT><BR><FONT size=3D2>&gt; &gt; be used by =
ISMS?&nbsp;=20
That seems like a lot of work for little overall </FONT><BR><FONT =
size=3D2>&gt;=20
&gt; benefit to the RADIUS community.</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
</FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I did =
assume that an=20
implementation-specific attribute to the RADIUS </FONT><BR><FONT =
size=3D2>&gt;=20
Access-Accept packet would pass unmodified through a RADIUS =
</FONT><BR><FONT=20
size=3D2>&gt; proxy, which </FONT><BR><FONT size=3D2>&gt; in fact is a =
matter of=20
proxy policy (RFC2865 , section 2.3). </FONT><BR><FONT size=3D2>&gt; =
With this=20
</FONT><BR><FONT size=3D2>&gt; erroneous assumption, I thought I was =
proposing an=20
</FONT><BR><FONT size=3D2>&gt; implementation-specific use of existing =
RADIUS=20
protocol </FONT><BR><FONT size=3D2>&gt; facility. I did </FONT><BR><FONT =

size=3D2>&gt; not expect any "benefit to the RADIUS community".</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
</FONT><BR><FONT size=3D2>&gt; &gt; Rather than designing a new version =
of RADIUS=20
to meet its needs, it </FONT><BR><FONT size=3D2>&gt; &gt; seems more =
profitable=20
for ISMS to either figure out how to use the </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
protocol as it exists today, or to summarize its </FONT><BR><FONT =
size=3D2>&gt;=20
requirements for new </FONT><BR><FONT size=3D2>&gt; &gt; work and ask =
that it be=20
chartered outside of ISMS.</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Point well taken. I just =
looked at=20
RFC3576, abstract reproduced below</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; "This document describes a =
currently=20
deployed extension </FONT><BR><FONT size=3D2>&gt; to the Remote</FONT> =
<BR><FONT=20
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Authentication Dial In User =
Service (RADIUS)=20
protocol, allowing</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; dynamic=20
changes to a user session, as implemented by </FONT><BR><FONT =
size=3D2>&gt;=20
network access</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
server=20
products.&nbsp; This includes support for disconnecting </FONT><BR><FONT =

size=3D2>&gt; users and</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
changing authorizations applicable to a user session."</FONT> <BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Unfortunately, the security =
section of=20
RFC3576 raises a number of </FONT><BR><FONT size=3D2>&gt; concerns. E.g. =
the=20
following sentence: "It is RECOMMENDED </FONT><BR><FONT size=3D2>&gt; =
that IPsec=20
be </FONT><BR><FONT size=3D2>&gt; employed to afford better =
security."</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Again, thanks for =
your=20
comments.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
--=20
</FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; - Thierry=20
Moreau</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
CONNOTECH=20
Experts-conseils inc.</FONT> <BR><FONT size=3D2>&gt; 9130 Place de=20
Montgolfier</FONT> <BR><FONT size=3D2>&gt; Montreal, Qc</FONT> <BR><FONT =

size=3D2>&gt; Canada&nbsp;&nbsp; H2M 2A1</FONT> <BR><FONT size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Tel.: (514)385-5691</FONT> <BR><FONT =
size=3D2>&gt;=20
Fax:&nbsp; (514)385-5900</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

size=3D2>&gt; web site: <A href=3D"http://www.connotech.com"=20
target=3D_blank>http://www.connotech.com</A></FONT> <BR><FONT =
size=3D2>&gt; e-mail:=20
thierry.moreau@connotech.com</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
Isms mailing list</FONT> <BR><FONT size=3D2>&gt; =
Isms@lists.ietf.org</FONT>=20
<BR><FONT size=3D2>&gt; <A =
href=3D"https://www1.ietf.org/mailman/listinfo/isms"=20
target=3D_blank>https://www1.ietf.org/mailman/listinfo/isms</A></FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT></P></BODY></HTML>

------=_NextPart_000_0087_01C54981.9B1F8470--


--===============1202129815==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1202129815==--




From isms-bounces@lists.ietf.org Mon Apr 25 22:01:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQFOK-0005vk-Ga; Mon, 25 Apr 2005 22:01:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQFOJ-0005vf-K6
	for isms@megatron.ietf.org; Mon, 25 Apr 2005 22:01:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21298
	for <isms@ietf.org>; Mon, 25 Apr 2005 22:01:33 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQFae-0004ef-TN
	for isms@ietf.org; Mon, 25 Apr 2005 22:14:22 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DQFOH-0003tW-8M; Mon, 25 Apr 2005 22:01:33 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3Q21VP30227;
	Mon, 25 Apr 2005 19:01:31 -0700
Date: Mon, 25 Apr 2005 19:01:31 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: "Glen Zorn (gwz)" <gwz@cisco.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <200504251729.j3PHT254017150@ams-core-1.cisco.com>
Message-ID: <Pine.LNX.4.56.0504251856130.29568@internaut.com>
References: <200504251729.j3PHT254017150@ams-core-1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Martin Soukup said:

> The use of RADIUS itself without a defined extension such as EAP-TLS
> or EAP-PEAP over RADIUS cannot securely pass attributes between
> entities. Note that the defined EAP-TLS (or other EAP mechanisms)
> over RADIUS provides for secure attribute passing between entities
> even through proxies.

In response to which, Glen Zorn spake thusly:

> I thought that I was passing familiar w/EAP-TLS (and even more so
> w/PEAP), but I am completely unaware of such capabilities.  Would
> you mind explaining how this is achieved, given that RADIUS & EAP
> are completely different protocols?

I also was unaware of the ability of EAP-TLS to transmit RADIUS attributes
between the EAP peer and server.  I had always thought RADIUS was a
protocol only spoken between a NAS and a RADIUS server, and that EAP-TLS
didn't support transmission of TLVs.  But I guess this is a somewhat old
fashioned point of view.

Perhaps this is referring to EAP-TLS "extended" via the following?
http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-01.txt



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 10:15:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQQmA-0002mu-RL; Tue, 26 Apr 2005 10:10:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQQm9-0002mp-Ro
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 10:10:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11173
	for <isms@ietf.org>; Tue, 26 Apr 2005 10:10:56 -0400 (EDT)
Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQQyZ-0005JY-9T
	for isms@ietf.org; Tue, 26 Apr 2005 10:23:50 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3QE9esU013768; 
	Tue, 26 Apr 2005 14:09:40 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com
	[132.233.42.128])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3QE9T4W000369; 
	Tue, 26 Apr 2005 14:09:38 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042607093714949 ; Tue, 26 Apr 2005 07:09:37 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 07:09:37 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 07:09:37 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 10:09:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 10:09:06 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290107C0D9@pysmsx401.amr.corp.intel.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Bernard Aboba" <aboba@internaut.com>, "Glen Zorn \(gwz\)" <gwz@cisco.com>
X-OriginalArrivalTime: 26 Apr 2005 14:09:35.0989 (UTC)
	FILETIME=[93B26250:01C54A69]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

It was my understanding that while EAP is between the client
(supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP method*
that runs on top of EAP is between the client and RADIUS server.=20

This tunnel created by EAP method can be considered as "trust between
the client and AAA", and RADIUS between NAS and AAA (however it is
accomplished) is "trust between NAS and AAA".=20

And yes, many find convenient to connect authorization decision to some
extra information about the supplicant - such as its posture evaluation
(Cisco NAC, Microsoft NAP, etc). Such information would naturally be
carried in TLVs as part of EAP inner method exchange. Yes it seems to go
way beyond the original purpose of EAP, but then it does seem to address
the today's need.

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Bernard Aboba
Sent: Monday, April 25, 2005 10:02 PM
To: Glen Zorn (gwz)
Cc: radiusext@ops.ietf.org; eap@frascone.com; isms@ietf.org
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

Martin Soukup said:

> The use of RADIUS itself without a defined extension such as EAP-TLS
> or EAP-PEAP over RADIUS cannot securely pass attributes between
> entities. Note that the defined EAP-TLS (or other EAP mechanisms)
> over RADIUS provides for secure attribute passing between entities
> even through proxies.

In response to which, Glen Zorn spake thusly:

> I thought that I was passing familiar w/EAP-TLS (and even more so
> w/PEAP), but I am completely unaware of such capabilities.  Would
> you mind explaining how this is achieved, given that RADIUS & EAP
> are completely different protocols?

I also was unaware of the ability of EAP-TLS to transmit RADIUS
attributes
between the EAP peer and server.  I had always thought RADIUS was a
protocol only spoken between a NAS and a RADIUS server, and that EAP-TLS
didn't support transmission of TLVs.  But I guess this is a somewhat old
fashioned point of view.

Perhaps this is referring to EAP-TLS "extended" via the following?
http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-ext
ension-01.txt



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 11:13:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQRkb-0001Wa-T3; Tue, 26 Apr 2005 11:13:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRkZ-0001WV-V3
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 11:13:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16739
	for <isms@ietf.org>; Tue, 26 Apr 2005 11:13:21 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQRx3-0006w7-96
	for isms@ietf.org; Tue, 26 Apr 2005 11:26:17 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 26 Apr 2005 17:13:14 +0200
Received: from gwzw2k01 (sjc-vpn2-220.cisco.com [10.21.112.220])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3QFD354016485; 
	Tue, 26 Apr 2005 17:13:04 +0200 (MEST)
Message-Id: <200504261513.j3QFD354016485@ams-core-1.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>,
	"'Bernard Aboba'" <aboba@internaut.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 08:12:58 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <3DEC199BD7489643817ECA151F7C59290107C0D9@pysmsx401.amr.corp.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Blumenthal, Uri <mailto:uri.blumenthal@intel.com> supposedly
scribbled:

> It was my understanding that while EAP is between the client
> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP
method*
> that runs on top of EAP is between the client and RADIUS server. 

No.  Can we just _get it_ once and for all?  AAA & EAP are
_different_ and _separate_ things: there is no part of EAP that is
"between" the EAP peer and any AAA entity.

> 
> This tunnel created by EAP method can be considered as "trust
between
> the client and AAA", 

See above.

> and RADIUS between NAS and AAA (however it is 
> accomplished) is "trust between NAS and AAA".
> 
> And yes, many find convenient to connect authorization decision to
> some extra information about the supplicant - such as its posture
> evaluation (Cisco NAC, Microsoft NAP, etc). Such information would
> naturally be carried in TLVs as part of EAP inner method exchange.

Or more rationally (gasp!) in a subsequent _authorization_ protocol
exchange.

> Yes it seems to go way beyond the original purpose of EAP, but
then
> it does seem to address the today's need.  

If one has a sore toe, shooting oneself in the foot may seem to
satisfy "today's need"; in the long run, however, it will probably
turn out to be counterproductive.
   
> 
> -----Original Message-----
> From: isms-bounces@lists.ietf.org
[mailto:isms-bounces@lists.ietf.org]
> On Behalf Of Bernard Aboba
> Sent: Monday, April 25, 2005 10:02 PM
> To: Glen Zorn (gwz)
> Cc: radiusext@ops.ietf.org; eap@frascone.com; isms@ietf.org
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> Martin Soukup said:
> 
>> The use of RADIUS itself without a defined extension such as
EAP-TLS
>> or EAP-PEAP over RADIUS cannot securely pass attributes between
>> entities. Note that the defined EAP-TLS (or other EAP mechanisms)
>> over RADIUS provides for secure attribute passing between
entities
>> even through proxies.
> 
> In response to which, Glen Zorn spake thusly:
> 
>> I thought that I was passing familiar w/EAP-TLS (and even more so
>> w/PEAP), but I am completely unaware of such capabilities.  Would
you
>> mind explaining how this is achieved, given that RADIUS & EAP are
>> completely different protocols?
> 
> I also was unaware of the ability of EAP-TLS to transmit RADIUS
> attributes between the EAP peer and server.  I had always thought
> RADIUS was a protocol only spoken between a NAS and a RADIUS
server,
> and that EAP-TLS didn't support transmission of TLVs.  But I guess
> this is a somewhat old fashioned point of view.    
> 
> Perhaps this is referring to EAP-TLS "extended" via the following?
>
http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application
-ext
> ension-01.txt
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 13:35:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQTy3-00060o-2D; Tue, 26 Apr 2005 13:35:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQTy1-00060b-I7
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 13:35:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28919
	for <isms@ietf.org>; Tue, 26 Apr 2005 13:35:22 -0400 (EDT)
Received: from ranger.systems.pipex.net ([62.241.162.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUAU-0002Px-Oe
	for isms@ietf.org; Tue, 26 Apr 2005 13:48:20 -0400
Received: from pc6 (1Cust244.tnt106.lnd4.gbr.da.uu.net [213.116.60.244])
	by ranger.systems.pipex.net (Postfix) with SMTP id 3681EE0002D4;
	Tue, 26 Apr 2005 18:35:11 +0100 (BST)
Message-ID: <025501c54a7d$663bf520$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>, <isms@ietf.org>
References: <3DEC199BD7489643817ECA151F7C59290103F269@pysmsx401.amr.corp.intel.com>
Date: Tue, 26 Apr 2005 18:29:38 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

<in-line>

(I keep falling behind with all this:-)

Tom Petch

----- Original Message -----
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>; "Nelson, David"
<dnelson@enterasys.com>; "Khanh Nguyen (khanhvn)" <khanhvn@cisco.com>;
<isms@ietf.org>
Sent: Thursday, April 21, 2005 11:43 PM
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party


But that was the whole problem! Admins did NOT want to enter a new set
of user-names and passwords in each agent, and then manage the lists.

Perhaps you miss my point.  The problem I first heard Wes articulate was the
need to update all (eg) 1000 agents when one of the (eg) 150 end-users of the
SNMP manager changed.  I am saying don't bother.  Predefine users (user1 to
usern) in
the agent independent of the end-users, the operator customises shared secrets
for as many or as few as he requires at installation of the agent and only
changes them in accordance with security policy (monthly, yearly, after a
security breach, never).  This keeps the agent simple.

An end-user accesses the manager using its customary user id, is authenticated
by a security server which grants permission for an SNMP session and which
creates an SNMP sesssion key based on the secret shared between security server
and agent (but not with the manager).

The manager/security server have more work to do but that is ok, there are few
of them, often surrounded by operational staff (at least compared to agents) so
increase the workload there to keep the agent simple.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 13:42:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQU4t-0006l1-Rk; Tue, 26 Apr 2005 13:42:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQU4s-0006kr-Cz
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 13:42:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29363
	for <isms@ietf.org>; Tue, 26 Apr 2005 13:42:29 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUHM-0002cO-3l
	for isms@ietf.org; Tue, 26 Apr 2005 13:55:25 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3QHgMbg011978
	for <isms@ietf.org>; Tue, 26 Apr 2005 13:42:22 -0400 (EDT)
Message-Id: <200504261742.j3QHgMbg011978@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
In-Reply-To: <025501c54a7d$663bf520$0601a8c0@pc6> 
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Tue, 26 Apr 2005 13:42:22 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

<wg chair hat off>

>Perhaps you miss my point.  The problem I first heard Wes articulate was the
>need to update all (eg) 1000 agents when one of the (eg) 150 end-users of the
>SNMP manager changed.  I am saying don't bother.  Predefine users (user1 to
>usern) in
>the agent independent of the end-users, the operator customises shared secrets
>for as many or as few as he requires at installation of the agent and only
>changes them in accordance with security policy (monthly, yearly, after a
>security breach, never).  This keeps the agent simple.

I would note that you can do that today with USM.  But we have a lot of
people saying that doesn't suffice for their needs.

<wg chair hat on>

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 14:14:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQUXH-0001Rn-92; Tue, 26 Apr 2005 14:11:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUXF-0001Ri-Kd
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 14:11:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01815
	for <isms@ietf.org>; Tue, 26 Apr 2005 14:11:48 -0400 (EDT)
Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUjj-0003Ts-Ab
	for isms@ietf.org; Tue, 26 Apr 2005 14:24:44 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3QIBXlb030323; 
	Tue, 26 Apr 2005 18:11:34 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com
	[132.233.42.124])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3QIAaUM014308; 
	Tue, 26 Apr 2005 18:11:33 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042611113219427 ; Tue, 26 Apr 2005 11:11:32 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 11:11:25 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 11:11:25 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 14:11:23 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Apr 2005 14:10:58 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290107C375@pysmsx401.amr.corp.intel.com>
Thread-Topic: Keep the agent simple; was RADIUS is not a trusted third party
Thread-Index: AcVKhlDuXVYU8cLySyyKqybsNhCa6AABMpUQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>, <isms@ietf.org>
X-OriginalArrivalTime: 26 Apr 2005 18:11:23.0887 (UTC)
	FILETIME=[5B13EFF0:01C54A8B]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Isms] RE: Keep the agent simple;
	was RADIUS is not a trusted third party
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>But that was the whole problem! Admins did NOT want to enter a new set
>>of user-names and passwords in each agent, and then manage the lists.
>
> Perhaps you miss my point.  The problem I first heard Wes articulate
was the
> need to update all (eg) 1000 agents when one of the (eg) 150 end-users
of the
> SNMP manager changed.  I am saying don't bother.  Predefine users
(user1 to
> usern) in the agent independent of the end-users, the operator
customises
> shared secrets for as many or as few as he requires at installation of
> the agent and only changes them in accordance with security policy
(monthly,
> yearly, after a security breach, never).  This keeps the agent simple.

Perhaps you miss my point. Because the above is _precisely_ what
operators do _not_ want to do.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 14:17:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQUd4-000240-KM; Tue, 26 Apr 2005 14:17:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUd2-00022b-G8
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 14:17:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02345
	for <isms@ietf.org>; Tue, 26 Apr 2005 14:17:47 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUpX-0003ay-64
	for isms@ietf.org; Tue, 26 Apr 2005 14:30:43 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3QIHbb0032310; 
	Tue, 26 Apr 2005 18:17:37 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com
	[132.233.42.129])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3QIHaFe031721; 
	Tue, 26 Apr 2005 18:17:36 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042611173610191 ; Tue, 26 Apr 2005 11:17:36 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 11:17:36 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 11:17:35 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Apr 2005 14:17:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 14:17:08 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C59290107C387@pysmsx401.amr.corp.intel.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwA==
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <gwz@cisco.com>, "Bernard Aboba" <aboba@internaut.com>
X-OriginalArrivalTime: 26 Apr 2005 18:17:34.0447 (UTC)
	FILETIME=[37F2E7F0:01C54A8C]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>> It was my understanding that while EAP is between the client
>> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP
>> method* that runs on top of EAP is between the client and RADIUS
>> server.=20
>
> No. Can we just _get it_ once and for all?  AAA & EAP are
> _different_ and _separate_ things: there is no part of EAP that is
> "between" the EAP peer and any AAA entity.

What about EAP methods that run between the EAP client and EAP server?
Are you saying that EAP _method_ does not terminate in an EAP server, or
that EAP server is not usually [within and part of] a AAA server? "EAP
server" is what "eap peer" and "aaa" share.
Oh and we _are_ talking EAPv2, right?


>> This tunnel created by EAP method can be considered as "trust
>> between the client and AAA",=20
>
> See above.

See above. I consider EAP server running inside AAA server. If others
(besides Glen and Bernard) on this list disagree with this perception -
I invite them to speak up please.=20


>> and RADIUS between NAS and AAA (however it is=20
>> accomplished) is "trust between NAS and AAA".
>>=20
>> And yes, many find convenient to connect authorization decision to
>> some extra information about the supplicant - such as its posture
>> evaluation (Cisco NAC, Microsoft NAP, etc). Such information would
>> naturally be carried in TLVs as part of EAP inner method exchange.
>
> Or more rationally (gasp!) in a subsequent _authorization_ protocol
> exchange.

Kindly explain how "authorization" doesn't include trust of the
authorizing entity. Also, it may be news for you - but [at least some]
people want authentication combined with authorization: i.e. if I get a
set of keys, it means that (a) the AAA authenticated me OK, _and_ (b)
that the server implicitly authorized me to communicate with the given
NAS.

That authorization is dependent on host posture evaluation. I thought it
was Cisco that proposed it in their NAC architecture? Perhaps you
can/should shed some light on this?


>> Yes it seems to go way beyond the original purpose of EAP, but
>> then it does seem to address the today's need. =20
>
> If one has a sore toe, shooting oneself in the foot may seem to
> satisfy "today's need"; in the long run, however, it will probably
> turn out to be counterproductive.
=20
I'm simply describing what I perceive as today's reality. You may
intensely dislike it - it's your free choice. Looks like the market is
moving the above-described way.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 14:17:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQUd6-00024T-R8; Tue, 26 Apr 2005 14:17:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUd4-00023u-8h
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 14:17:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02348
	for <isms@ietf.org>; Tue, 26 Apr 2005 14:17:49 -0400 (EDT)
Received: from astro.systems.pipex.net ([62.241.163.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUpY-0003az-98
	for isms@ietf.org; Tue, 26 Apr 2005 14:30:45 -0400
Received: from pc6 (1Cust110.tnt106.lnd4.gbr.da.uu.net [213.116.60.110])
	by astro.systems.pipex.net (Postfix) with SMTP id D2B2CE000148;
	Tue, 26 Apr 2005 19:17:34 +0100 (BST)
Message-ID: <008401c54a83$5384a3e0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <isms@ietf.org>, "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
References: <200504261742.j3QHgMbg011978@ginger.cmf.nrl.navy.mil>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Tue, 26 Apr 2005 19:11:53 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Mmm I must have some more gaps in my knowledge of USM:-)

1) I log on as TP377 using a secret known to me and the enterprise-wide security
server

2) The security server authenticates me and generates a key based on a secret
shared by security server and SNMP agent (probably localised by engine id) and
unknown to TP377 or the SNMP manager

3) The security server tells the SNMP manager TP377 is authorised to use the
SNMP manager to access SNMP agents (perhaps limited by IP address)  with
userName userj and the key it has generated

4) The SNMP manager sets up a secure channel with the SNMP agent using userName
userj and that key.

What I am missing is how the USM in the SNMP manager lets me do this, the
protocol it uses with the security server.

Tom Petch
----- Original Message -----
From: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
To: <isms@ietf.org>
Sent: Tuesday, April 26, 2005 7:42 PM
Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party


> <wg chair hat off>
>
> >Perhaps you miss my point.  The problem I first heard Wes articulate was the
> >need to update all (eg) 1000 agents when one of the (eg) 150 end-users of the
> >SNMP manager changed.  I am saying don't bother.  Predefine users (user1 to
> >usern) in
> >the agent independent of the end-users, the operator customises shared
secrets
> >for as many or as few as he requires at installation of the agent and only
> >changes them in accordance with security policy (monthly, yearly, after a
> >security breach, never).  This keeps the agent simple.
>
> I would note that you can do that today with USM.  But we have a lot of
> people saying that doesn't suffice for their needs.
>
> <wg chair hat on>
>
> --Ken
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 14:27:49 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQUmj-0003s6-8r; Tue, 26 Apr 2005 14:27:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUmi-0003s1-Fv
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 14:27:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03187
	for <isms@ietf.org>; Tue, 26 Apr 2005 14:27:45 -0400 (EDT)
Message-Id: <200504261827.OAA03187@ietf.org>
Received: from rwcrmhc13.comcast.net ([204.127.198.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUzA-0003pU-Ei
	for isms@ietf.org; Tue, 26 Apr 2005 14:40:41 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc13) with SMTP
	id <20050426182732015004t4d7e>; Tue, 26 Apr 2005 18:27:32 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>, <gwz@cisco.com>,
	"'Bernard Aboba'" <aboba@internaut.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 14:27:24 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAACLjdQ
In-Reply-To: <3DEC199BD7489643817ECA151F7C59290107C387@pysmsx401.amr.corp.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: 7bit
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Why are we spending so much time discussing EAP, if the AD has told
the WG that EAP should not be used, and that the IESG is unlikely to
approve a solution using EAP?

dbh

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri
> Sent: Tuesday, April 26, 2005 2:17 PM
> To: gwz@cisco.com; Bernard Aboba
> Cc: radiusext@ops.ietf.org; eap@frascone.com; isms@ietf.org
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> >> It was my understanding that while EAP is between the client
> >> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP
> >> method* that runs on top of EAP is between the client and RADIUS
> >> server. 
> >
> > No. Can we just _get it_ once and for all?  AAA & EAP are
> > _different_ and _separate_ things: there is no part of EAP that is
> > "between" the EAP peer and any AAA entity.
> 
> What about EAP methods that run between the EAP client and EAP
server?
> Are you saying that EAP _method_ does not terminate in an EAP 
> server, or
> that EAP server is not usually [within and part of] a AAA server?
"EAP
> server" is what "eap peer" and "aaa" share.
> Oh and we _are_ talking EAPv2, right?
> 
> 
> >> This tunnel created by EAP method can be considered as "trust
> >> between the client and AAA", 
> >
> > See above.
> 
> See above. I consider EAP server running inside AAA server. If
others
> (besides Glen and Bernard) on this list disagree with this 
> perception -
> I invite them to speak up please. 
> 
> 
> >> and RADIUS between NAS and AAA (however it is 
> >> accomplished) is "trust between NAS and AAA".
> >> 
> >> And yes, many find convenient to connect authorization decision
to
> >> some extra information about the supplicant - such as its posture
> >> evaluation (Cisco NAC, Microsoft NAP, etc). Such information
would
> >> naturally be carried in TLVs as part of EAP inner method
exchange.
> >
> > Or more rationally (gasp!) in a subsequent _authorization_
protocol
> > exchange.
> 
> Kindly explain how "authorization" doesn't include trust of the
> authorizing entity. Also, it may be news for you - but [at least
some]
> people want authentication combined with authorization: i.e. 
> if I get a
> set of keys, it means that (a) the AAA authenticated me OK, _and_
(b)
> that the server implicitly authorized me to communicate with the
given
> NAS.
> 
> That authorization is dependent on host posture evaluation. I 
> thought it
> was Cisco that proposed it in their NAC architecture? Perhaps you
> can/should shed some light on this?
> 
> 
> >> Yes it seems to go way beyond the original purpose of EAP, but
> >> then it does seem to address the today's need.  
> >
> > If one has a sore toe, shooting oneself in the foot may seem to
> > satisfy "today's need"; in the long run, however, it will probably
> > turn out to be counterproductive.
>  
> I'm simply describing what I perceive as today's reality. You may
> intensely dislike it - it's your free choice. Looks like the market
is
> moving the above-described way.
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 14:34:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQUtA-0004bT-9m; Tue, 26 Apr 2005 14:34:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUt9-0004bO-4k
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 14:34:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03623
	for <isms@ietf.org>; Tue, 26 Apr 2005 14:34:25 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQV5d-0003y5-Bb
	for isms@ietf.org; Tue, 26 Apr 2005 14:47:22 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3QIYHmW013250
	for <isms@ietf.org>; Tue, 26 Apr 2005 14:34:17 -0400 (EDT)
Message-Id: <200504261834.j3QIYHmW013250@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
In-Reply-To: <008401c54a83$5384a3e0$0601a8c0@pc6> 
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Tue, 26 Apr 2005 14:34:17 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>Mmm I must have some more gaps in my knowledge of USM:-)

Weeelll ... I guess it's all semantics.

You were saying (as I understood it) instead of having hundreds of users,
have a smaller number of "role-based" users, to limit the number of keys
that need to be changed.

You can do the same thing with USM (have a smaller number of role-based
users to limit the keys).  Now, they aren't part of your security
infrastructure, but it's a moot point.  The feedback we've gotten from
operators is that they want to be able to use their regular user
accounts to authenticate to SNMP, not role-based accounts.

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 15:04:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQVMg-00087M-15; Tue, 26 Apr 2005 15:04:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQVMe-00087H-7u
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 15:04:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06042
	for <isms@ietf.org>; Tue, 26 Apr 2005 15:04:54 -0400 (EDT)
Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQVZ8-0004au-GK
	for isms@ietf.org; Tue, 26 Apr 2005 15:17:51 -0400
Received: (from uucp@localhost)
	by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA26435
	for <isms@ietf.org>; Tue, 26 Apr 2005 15:05:57 -0400 (EDT)
Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap
	(4.1) id xma026391; Tue, 26 Apr 05 15:05:32 -0400
Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan
	Messaging Security Suite; Tue, 26 Apr 2005 15:04:24 -0400
Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; 
	Tue, 26 Apr 2005 15:04:24 -0400
Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with
	Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Apr 2005 15:03:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 15:03:33 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322FA@MAANDMBX2.ets.enterasys.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAADRxYA
From: "Nelson, David" <dnelson@enterasys.com>
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>, <gwz@cisco.com>,
	"Bernard Aboba" <aboba@internaut.com>
X-OriginalArrivalTime: 26 Apr 2005 19:03:36.0194 (UTC)
	FILETIME=[A6140E20:01C54A92]
X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8
X-pstn-levels: (C:90.6865 M:96.2375 P:95.9108 R:95.9108 S:38.2676 )
X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13
X-pstn-addresses: from <dnelson@enterasys.com> forward (org good) 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org


Uri Blumenthal writes...

> I consider EAP server running inside AAA server. If others
> (besides Glen and Bernard) on this list disagree with this perception
-
> I invite them to speak up please.

I agree that is most often the case, in practice.  The EAP server is
packaged as part of the RADIUS or Diameter server software distribution.


>From a protocol definition perspective, however, the EAP server and AAA
server are distinct entities.  Any interaction (API) between these
entities is outside the scope of the EAP, RADIUS or Diameter RFCs. Any
security analysis of those protocols cannot take into account the AAA
server to EAP server API, as it is implementation specific.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 15:08:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQVPp-0008OK-UX; Tue, 26 Apr 2005 15:08:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQVPo-0008OF-NB
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 15:08:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06459
	for <isms@ietf.org>; Tue, 26 Apr 2005 15:08:11 -0400 (EDT)
Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQVcK-0004eH-4H
	for isms@ietf.org; Tue, 26 Apr 2005 15:21:08 -0400
Received: (from uucp@localhost)
	by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA26648
	for <isms@ietf.org>; Tue, 26 Apr 2005 15:09:17 -0400 (EDT)
Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap
	(4.1) id xma026593; Tue, 26 Apr 05 15:09:07 -0400
Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by
	134.141.79.124 with InterScan Messaging Security Suite;
	Tue, 26 Apr 2005 15:07:57 -0400
Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; 
	Tue, 26 Apr 2005 15:07:57 -0400
Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with
	Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Apr 2005 15:07:16 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 15:07:14 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322FB@MAANDMBX2.ets.enterasys.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAACLjdQAAFWx2A=
From: "Nelson, David" <dnelson@enterasys.com>
To: <ietfdbh@comcast.net>, "Blumenthal, Uri" <uri.blumenthal@intel.com>,
	<gwz@cisco.com>, "Bernard Aboba" <aboba@internaut.com>
X-OriginalArrivalTime: 26 Apr 2005 19:07:16.0288 (UTC)
	FILETIME=[2943BC00:01C54A93]
X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8
X-pstn-levels: (C:92.2131 M:98.8113 P:95.9108 R:95.9108 S:21.1072 )
X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13
X-pstn-addresses: from <dnelson@enterasys.com> forward (org good) 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Dave Harrington writes...

> Why are we spending so much time discussing EAP, if the AD has told
> the WG that EAP should not be used, and that the IESG is unlikely to
> approve a solution using EAP?

I don't know.  But I'll offer the somewhat pedantic clarification that
the AD told ISMS that EAP was out of scope because of the EAP
applicability statement.  There exists the finite possibility that the
EAP WG will decide to modify its applicability statement.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 15:28:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQVjI-0002Wv-FO; Tue, 26 Apr 2005 15:28:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQVjG-0002Vp-L5
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 15:28:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09036
	for <isms@ietf.org>; Tue, 26 Apr 2005 15:28:17 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQVvl-00056T-66
	for isms@ietf.org; Tue, 26 Apr 2005 15:41:14 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 26 Apr 2005 12:28:08 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3QJRWiM021450;
	Tue, 26 Apr 2005 12:28:06 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 26 Apr 2005 12:28:03 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 12:28:02 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13FAB8@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Thread-Index: AcVKhob4ah16mNTYRqKyIrUz2wo8swAAThsQ
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>,
	"Blumenthal, Uri" <uri.blumenthal@intel.com>, <isms@ietf.org>
X-OriginalArrivalTime: 26 Apr 2005 19:28:03.0682 (UTC)
	FILETIME=[10C4F420:01C54A96]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Good point.  I am glad that Tom brought up this important issue=20
about user management, and I'd like to elaborate this point
a little bit.

I guess we all agree that with the growing sizes and complexity=20
of today networks, network management is moving toward end-to-end,=20
service-oriented, not just individual device mgmt.  Opearators=20
now-a-day are increasingly using centralized applications (such=20
as Cisco Works, etc.) to manage the networks as a whole instead of=20
dealing directly with the devices individually. =20

Old Model:

User <--> SNMP Manager <--> SNMP Agent (Device)

New Model:

User <-> Client Console <-> Centralized Server <-> SNMP Agent

These centralized servers (Cisco Works, HP OpenView, etc) often=20
provide web-based and/or GUI interface and have their own user=20
auth & access control.

Doing user access control at the centralized manager instead
of at the device (instrumentation) level has many advantages:

1. The centralized manager has a global view of the network
as well as the global security policies, so it can provide
a more complete and consistent user access control. =20

2. Easy to manage.  There is one/a few centralized server(s),=20
so adding or changing users is simpler.  Integration with AAA=20
(radius/tacacs+) is also much easier (only a few, not thousands,=20
of AAA clients to manage).

So as Tom pointed out, it's better to configure SNMP agents
with just one or a few predefined "users", mainly to auth b/w=20
the centralized manager and the agents.  The "real" end users
are handled by the centralized managers, not by the individual
devices. =20

Ultimately, we may not even need the concept of a "user" at
the SNMP instrumentation (agent) level.  Some simple scheme=20
such as a community-based access control can be used as an=20
alternative to the user-based access control model.  But=20
that's a different topic...

Just my 2c.

Khanh

> -----Original Message-----
> From: isms-bounces@lists.ietf.org=20
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch
> Sent: Tuesday, April 26, 2005 9:30 AM
> To: Blumenthal, Uri; isms@ietf.org
> Subject: [Isms] Keep the agent simple;was RADIUS is not a=20
> trusted third party
>=20
> <in-line>
>=20
> (I keep falling behind with all this:-)
>=20
> Tom Petch
>=20
> ----- Original Message -----
> From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
> To: "Tom Petch" <nwnetworks@dial.pipex.com>; "Nelson, David"
> <dnelson@enterasys.com>; "Khanh Nguyen (khanhvn)"=20
> <khanhvn@cisco.com>; <isms@ietf.org>
> Sent: Thursday, April 21, 2005 11:43 PM
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
>=20
>=20
> But that was the whole problem! Admins did NOT want to enter=20
> a new set of user-names and passwords in each agent, and then=20
> manage the lists.
>=20
> Perhaps you miss my point.  The problem I first heard Wes=20
> articulate was the need to update all (eg) 1000 agents when=20
> one of the (eg) 150 end-users of the SNMP manager changed.  I=20
> am saying don't bother.  Predefine users (user1 to
> usern) in
> the agent independent of the end-users, the operator=20
> customises shared secrets for as many or as few as he=20
> requires at installation of the agent and only changes them=20
> in accordance with security policy (monthly, yearly, after a=20
> security breach, never).  This keeps the agent simple.
>=20
> An end-user accesses the manager using its customary user id,=20
> is authenticated by a security server which grants permission=20
> for an SNMP session and which creates an SNMP sesssion key=20
> based on the secret shared between security server and agent=20
> (but not with the manager).
>=20
> The manager/security server have more work to do but that is=20
> ok, there are few of them, often surrounded by operational=20
> staff (at least compared to agents) so increase the workload=20
> there to keep the agent simple.
>=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 16:33:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQWkB-00032Z-VJ; Tue, 26 Apr 2005 16:33:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWkA-00032R-HV
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 16:33:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14792
	for <isms@ietf.org>; Tue, 26 Apr 2005 16:33:15 -0400 (EDT)
Received: from astro.systems.pipex.net ([62.241.163.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQWwf-0006pv-2P
	for isms@ietf.org; Tue, 26 Apr 2005 16:46:14 -0400
Received: from pc6 (1Cust13.tnt27.lnd4.gbr.da.uu.net [62.188.154.13])
	by astro.systems.pipex.net (Postfix) with SMTP id 9BBF1E000282;
	Tue, 26 Apr 2005 21:33:02 +0100 (BST)
Message-ID: <00e601c54a96$3fa5afa0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <isms@ietf.org>, "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
References: <200504261834.j3QIYHmW013250@ginger.cmf.nrl.navy.mil>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Tue, 26 Apr 2005 21:29:09 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

But I am suggesting that humans use the same userid/password/security
credentials to logon whatever they are doing on whatever system - Telnet, SAP,
FTP, ... - using the organisation-wide security servers which is what I
understand operators want.

But this id is not used in the actual session between manager and agent (because
that means a change of human requires a change in every agent) so the SNMP
security system aided by the security server maps the human userid to one of a
small fixed pool in the agent (which shares a secret with the security server so
that they both can derive a session key when a human wants one).

This parallels what I see in use at present for non-SNMP (ftp, telnet) systems
with proprietary security.

Tom Petch

----- Original Message -----
From: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
To: <isms@ietf.org>
Sent: Tuesday, April 26, 2005 8:34 PM
Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party


> >Mmm I must have some more gaps in my knowledge of USM:-)
>
> Weeelll ... I guess it's all semantics.
>
> You were saying (as I understood it) instead of having hundreds of users,
> have a smaller number of "role-based" users, to limit the number of keys
> that need to be changed.
>
> You can do the same thing with USM (have a smaller number of role-based
> users to limit the keys).  Now, they aren't part of your security
> infrastructure, but it's a moot point.  The feedback we've gotten from
> operators is that they want to be able to use their regular user
> accounts to authenticate to SNMP, not role-based accounts.
>
> --Ken
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 16:38:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQWop-0003sZ-D4; Tue, 26 Apr 2005 16:38:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWoo-0003sU-3G
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 16:38:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15095
	for <isms@ietf.org>; Tue, 26 Apr 2005 16:38:04 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQX1H-0006vU-DK
	for isms@ietf.org; Tue, 26 Apr 2005 16:51:02 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3QKbsTL016489
	for <isms@ietf.org>; Tue, 26 Apr 2005 16:37:54 -0400 (EDT)
Message-Id: <200504262037.j3QKbsTL016489@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
In-Reply-To: <00e601c54a96$3fa5afa0$0601a8c0@pc6> 
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Tue, 26 Apr 2005 16:37:54 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>But this id is not used in the actual session between manager and agent (because
>that means a change of human requires a change in every agent)

Ah.  This of course depends on the security infrastructure that you use.
I can think of several that do not require that (only one change is required
in one place).

I think if an operator wants to the system that you describe, then
that's fine (and I don't think anything that we've discussed will
prevent that), but from what I understood plenty of operators want to
use their "user" identities directly with SNMP.

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 16:52:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQX2U-0005S3-4c; Tue, 26 Apr 2005 16:52:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQX2S-0005Qc-IJ
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 16:52:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16334
	for <isms@ietf.org>; Tue, 26 Apr 2005 16:52:10 -0400 (EDT)
Message-Id: <200504262052.QAA16334@ietf.org>
Received: from rwcrmhc11.comcast.net ([204.127.198.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQXEy-0007DN-OV
	for isms@ietf.org; Tue, 26 Apr 2005 17:05:09 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc11) with SMTP
	id <2005042620520101300dclice>; Tue, 26 Apr 2005 20:52:02 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Tom Petch'" <nwnetworks@dial.pipex.com>, <isms@ietf.org>,
	"'Ken Hornstein'" <kenh@cmf.nrl.navy.mil>
Subject: RE: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Tue, 26 Apr 2005 16:51:55 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVKnzr/9o/L8mFXTpiGQWt8QtmRYAAANEIQ
In-Reply-To: <00e601c54a96$3fa5afa0$0601a8c0@pc6>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Comment #1:
One intention of the SNMPv3 approach was to enable logging of changes,
including logging the securityName of the security principal. In your
solution, there would be no security principal known at the agent, so
audit logs could not be done. Is this correct?

Comment#2:
Some applications already provide for user authentication via a
centralized server, and then use the identity of the application as
the SNMPv3 user. This allows for a very limited number of SNMPv3 users
at the agent, while allowing user-specific authentication at the
application. The application authorizes the authenticated user to
utilize its user-independent application identity for SNMPv3. 

Your suggestion depends on a third-party server to provide a similar
mapping between the authenticated-user at the application and a
user-independent identity temporarily assigned by an
authentication/authorization server used as the SNMPv3-user. Is that
correct?

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch
> Sent: Tuesday, April 26, 2005 3:29 PM
> To: isms@ietf.org; Ken Hornstein
> Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a 
> trusted third party 
> 
> But I am suggesting that humans use the same
userid/password/security
> credentials to logon whatever they are doing on whatever 
> system - Telnet, SAP,
> FTP, ... - using the organisation-wide security servers which 
> is what I
> understand operators want.
> 
> But this id is not used in the actual session between manager 
> and agent (because
> that means a change of human requires a change in every 
> agent) so the SNMP
> security system aided by the security server maps the human 
> userid to one of a
> small fixed pool in the agent (which shares a secret with the 
> security server so
> that they both can derive a session key when a human wants one).
> 
> This parallels what I see in use at present for non-SNMP 
> (ftp, telnet) systems
> with proprietary security.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
> To: <isms@ietf.org>
> Sent: Tuesday, April 26, 2005 8:34 PM
> Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a 
> trusted third
> party
> 
> 
> > >Mmm I must have some more gaps in my knowledge of USM:-)
> >
> > Weeelll ... I guess it's all semantics.
> >
> > You were saying (as I understood it) instead of having 
> hundreds of users,
> > have a smaller number of "role-based" users, to limit the 
> number of keys
> > that need to be changed.
> >
> > You can do the same thing with USM (have a smaller number 
> of role-based
> > users to limit the keys).  Now, they aren't part of your security
> > infrastructure, but it's a moot point.  The feedback we've 
> gotten from
> > operators is that they want to be able to use their regular user
> > accounts to authenticate to SNMP, not role-based accounts.
> >
> > --Ken
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 17:22:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQXVY-0001Ry-Pc; Tue, 26 Apr 2005 17:22:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXVX-0001Rs-0b
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 17:22:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18829
	for <isms@ietf.org>; Tue, 26 Apr 2005 17:22:12 -0400 (EDT)
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQXi0-0007tI-AA
	for isms@ietf.org; Tue, 26 Apr 2005 17:35:11 -0400
Received: from [192.168.0.128] (HSI-KBW-082-212-048-130.hsi.kabelbw.de
	[82.212.48.130])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 23CAD1BAC9E
	for <isms@ietf.org>; Tue, 26 Apr 2005 23:21:55 +0200 (CEST)
Date: Tue, 26 Apr 2005 23:21:53 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: isms@ietf.org
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Message-ID: <75F1B11B7830A96E6F82DA9E@[192.168.0.128]>
In-Reply-To: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Dear all,

We have to come to an agreement on the architecture we will use.
Ken asked some days ago, but only one of the replies stated a clear
position.

Shall I take this as an indicator that the rest is not decided yet?
Or does not care?  Or can we go on with the table that Robert posted?

>
> Keying|      For             | Against | Abstain
> ------+----------------------+---------+-------------
> OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
>
>
> Key:  Y=YES/preference    (y=second pref/implied pref)
>       M=MAYBE/second pref (m=implied second pref)
>       N=NO
>       -=no explicit rejection (no comment)
>
> OOB | IB  | EK  | Name (alphabetical by first name)
> ----+-----+-----+----------------------------------
>  N  |  N  |  Y  | David Harrington
>  -  |  y  |  -  | David Perkins
>  N  |  Y  |  M  | Ira McDonald
>  M  |  -  |  Y  | Juergen Schoenwaelder
>  Y  |  M  |  -  | Kaushik Narayan
>  Y  |  -  |  -  | Marcus Leech
>  Y  |  -  |  M  | Martin Soukup
>  N  |  Y  |  M  | Robert Story
>  m  |  y  |  Y  | Sam Hartman
>  Y  |  -  |  m  | Sharon Chisolm
>  -  |  M  |  Y  | Tom Petch
>  -  |  Y  |  Y  | Uri Blumenthal
>  -  |  Y  |  M  | Wes Hardaker
>

Has anybody changed her/his mind?
Or does anybody want to replace a dash by a letter?

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de



--On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:

> ISMS members,
>
> There's been a lot of discussion recently on the mailing list about the
> pros and cons of different security models.  I think the discussion has
> been good, but unfortunately I don't think it's getting any closer to a
> consensus (I thank Robert for trying to draw things closer;
> unfortunately Juergen and I have been rather busy off-line, and I
> apologize for that).  I know that some on the mailing list have
> expressed a preference for choosing a security protocol first, but
> we've been tasked with choosing the architecture first, and I believe
> that is the appropriate approach.
>
> Anyway, I'd like to call for a consensus on the security architecture.
> As we all know, the three choices are:
>
> - Out of band keying (the architecture used by EUSM)
> - In-bakd keying (the architecture used by SBSM)
> - Encapsulation keying (the architecture used by TLSM)
>
> What I would like to see is WG members express which architecture(s)
> they prefer (you can choose more than one, but please, don't choose all
> three).  Please feel free to state your reasons for your choices, but
> in the interests of reaching consensus in a reasonable timeframe, I am
> asking that WG members please refrain from commenting on other people's
> choices unless they feel that the person has stated a fact which is
> obviously wrong.
>
> Thanks for your time,
>
> --Ken
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 17:45:08 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQXrg-00059Q-CK; Tue, 26 Apr 2005 17:45:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXrZ-00056K-WA
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 17:45:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20609
	for <isms@ietf.org>; Tue, 26 Apr 2005 17:44:59 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQY43-0008LJ-Ow
	for isms@ietf.org; Tue, 26 Apr 2005 17:57:58 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50)
	id 1DQXrT-0003rA-3d; Tue, 26 Apr 2005 17:44:55 -0400
Date: Tue, 26 Apr 2005 17:44:56 -0400
From: Robert Story <rstory@freesnmp.com>
To: ietfdbh@comcast.net
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
Message-ID: <20050426174456.3f2d00b6@aud>
In-Reply-To: <200504261827.OAA03187@ietf.org>
References: <3DEC199BD7489643817ECA151F7C59290107C387@pysmsx401.amr.corp.intel.com>
	<200504261827.OAA03187@ietf.org>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Cc: radiusext@ops.ietf.org, eap@frascone.com,
	'Bernard Aboba' <aboba@internaut.com>, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

On Tue, 26 Apr 2005 14:27:24 -0400 David wrote:
DBH> Why are we spending so much time discussing EAP, if the AD has told
DBH> the WG that EAP should not be used, and that the IESG is unlikely to
DBH> approve a solution using EAP?

I've been wondering the same thing, but also include RADIUS, as that is just
one possible component of OOBK, which hasn't been selected as the
architecture..

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 17:52:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQXyb-0006ZA-8d; Tue, 26 Apr 2005 17:52:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXyZ-0006Yp-74
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 17:52:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21476
	for <isms@ietf.org>; Tue, 26 Apr 2005 17:52:12 -0400 (EDT)
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQYB2-00005C-L9
	for isms@ietf.org; Tue, 26 Apr 2005 18:05:12 -0400
Received: from [192.168.0.128] (HSI-KBW-082-212-048-130.hsi.kabelbw.de
	[82.212.48.130])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id D09651BAC9E
	for <isms@ietf.org>; Tue, 26 Apr 2005 23:52:01 +0200 (CEST)
Date: Tue, 26 Apr 2005 23:52:04 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: isms@ietf.org
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Message-ID: <F446FFD8620BE86B12EAD243@[192.168.0.128]>
In-Reply-To: <75F1B11B7830A96E6F82DA9E@[192.168.0.128]>
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
	<75F1B11B7830A96E6F82DA9E@[192.168.0.128]>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Here is my position as technical contributor:

I supported the position stated in the proposal comparison draft
(Yes for EUSM).  But with EAP being out of the game, I have a problem
supporting an architecture for which I do not see the required
protocols available.

I do not think we should develop our own security protocol.
Therefore, I am clearly against IB.

What remains is EK.

EK: Y
IB: N
OOB: -

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


--On 4/26/2005 11:21 PM +0200 Juergen Quittek wrote:

> Dear all,
>
> We have to come to an agreement on the architecture we will use.
> Ken asked some days ago, but only one of the replies stated a clear
> position.
>
> Shall I take this as an indicator that the rest is not decided yet?
> Or does not care?  Or can we go on with the table that Robert posted?
>
>>
>> Keying|      For             | Against | Abstain
>> ------+----------------------+---------+-------------
>> OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
>> IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
>> EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
>>
>>
>> Key:  Y=YES/preference    (y=second pref/implied pref)
>>       M=MAYBE/second pref (m=implied second pref)
>>       N=NO
>>       -=no explicit rejection (no comment)
>>
>> OOB | IB  | EK  | Name (alphabetical by first name)
>> ----+-----+-----+----------------------------------
>>  N  |  N  |  Y  | David Harrington
>>  -  |  y  |  -  | David Perkins
>>  N  |  Y  |  M  | Ira McDonald
>>  M  |  -  |  Y  | Juergen Schoenwaelder
>>  Y  |  M  |  -  | Kaushik Narayan
>>  Y  |  -  |  -  | Marcus Leech
>>  Y  |  -  |  M  | Martin Soukup
>>  N  |  Y  |  M  | Robert Story
>>  m  |  y  |  Y  | Sam Hartman
>>  Y  |  -  |  m  | Sharon Chisolm
>>  -  |  M  |  Y  | Tom Petch
>>  -  |  Y  |  Y  | Uri Blumenthal
>>  -  |  Y  |  M  | Wes Hardaker
>>
>
> Has anybody changed her/his mind?
> Or does anybody want to replace a dash by a letter?
>
> Thanks,
>
>     Juergen
> --
> Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
>
>
>
> --On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
>
>> ISMS members,
>>
>> There's been a lot of discussion recently on the mailing list about the
>> pros and cons of different security models.  I think the discussion has
>> been good, but unfortunately I don't think it's getting any closer to a
>> consensus (I thank Robert for trying to draw things closer;
>> unfortunately Juergen and I have been rather busy off-line, and I
>> apologize for that).  I know that some on the mailing list have
>> expressed a preference for choosing a security protocol first, but
>> we've been tasked with choosing the architecture first, and I believe
>> that is the appropriate approach.
>>
>> Anyway, I'd like to call for a consensus on the security architecture.
>> As we all know, the three choices are:
>>
>> - Out of band keying (the architecture used by EUSM)
>> - In-bakd keying (the architecture used by SBSM)
>> - Encapsulation keying (the architecture used by TLSM)
>>
>> What I would like to see is WG members express which architecture(s)
>> they prefer (you can choose more than one, but please, don't choose all
>> three).  Please feel free to state your reasons for your choices, but
>> in the interests of reaching consensus in a reasonable timeframe, I am
>> asking that WG members please refrain from commenting on other people's
>> choices unless they feel that the person has stated a fact which is
>> obviously wrong.
>>
>> Thanks for your time,
>>
>> --Ken
>>
>> _______________________________________________
>> Isms mailing list
>> Isms@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/isms
>
>
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 18:26:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQYVG-0002rJ-EF; Tue, 26 Apr 2005 18:26:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQYVF-0002r8-3h
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 18:26:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25261
	for <isms@ietf.org>; Tue, 26 Apr 2005 18:25:58 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQYhi-0000jw-9g
	for isms@ietf.org; Tue, 26 Apr 2005 18:38:58 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DQYV2-000HTb-9Z; Tue, 26 Apr 2005 18:25:48 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3QMPk109908;
	Tue, 26 Apr 2005 15:25:46 -0700
Date: Tue, 26 Apr 2005 15:25:46 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: "Glen Zorn (gwz)" <gwz@cisco.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <200504261513.j3QFD354016485@ams-core-1.cisco.com>
Message-ID: <Pine.LNX.4.56.0504261525040.9833@internaut.com>
References: <200504261513.j3QFD354016485@ams-core-1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: isms@ietf.org, radiusext@ops.ietf.org, eap@frascone.com
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> If one has a sore toe, shooting oneself in the foot may seem to
> satisfy "today's need"; in the long run, however, it will probably
> turn out to be counterproductive.

"Probably".  I sense a window large enough for an elephant to walk through
:)

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 18:33:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQYcX-0003l2-F0; Tue, 26 Apr 2005 18:33:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQYcV-0003ks-GK
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 18:33:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25774
	for <isms@ietf.org>; Tue, 26 Apr 2005 18:33:26 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQYoy-0000sr-Mj
	for isms@ietf.org; Tue, 26 Apr 2005 18:46:26 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DQYcP-000JSW-TR; Tue, 26 Apr 2005 18:33:26 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3QMXNG10513;
	Tue, 26 Apr 2005 15:33:23 -0700
Date: Tue, 26 Apr 2005 15:33:23 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: David B Harrington <ietfdbh@comcast.net>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <200504261827.j3QIRcS27781@internaut.com>
Message-ID: <Pine.LNX.4.56.0504261532430.9833@internaut.com>
References: <200504261827.j3QIRcS27781@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: radiusext@ops.ietf.org, isms@ietf.org, eap@frascone.com
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> Why are we spending so much time discussing EAP, if the AD has told
> the WG that EAP should not be used, and that the IESG is unlikely to
> approve a solution using EAP?
>
> dbh

Perhaps because the ISMS WG charter talks about RADIUS support?

Just a thought :)

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 18:46:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQYp2-0005MY-Gd; Tue, 26 Apr 2005 18:46:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQYp1-0005MT-Jp
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 18:46:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26653
	for <isms@ietf.org>; Tue, 26 Apr 2005 18:46:20 -0400 (EDT)
Message-Id: <200504262246.SAA26653@ietf.org>
Received: from rwcrmhc12.comcast.net ([216.148.227.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQZ1R-000179-KG
	for isms@ietf.org; Tue, 26 Apr 2005 18:59:20 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (rwcrmhc12) with SMTP
	id <2005042622461001400l0ca4e>; Tue, 26 Apr 2005 22:46:10 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Juergen Quittek'" <quittek@netlab.nec.de>, <isms@ietf.org>
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Tue, 26 Apr 2005 18:46:04 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVKpmk0MFirWMn7SVOPG5M3iEzSfQACv5MQ
In-Reply-To: <75F1B11B7830A96E6F82DA9E@[192.168.0.128]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi,

EK - yes
IB - maybe
OOB - maybe

dbh 

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek
> Sent: Tuesday, April 26, 2005 5:22 PM
> To: isms@ietf.org
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> Dear all,
> 
> We have to come to an agreement on the architecture we will use.
> Ken asked some days ago, but only one of the replies stated a clear
> position.
> 
> Shall I take this as an indicator that the rest is not decided yet?
> Or does not care?  Or can we go on with the table that Robert
posted?
> 
> >
> > Keying|      For             | Against | Abstain
> > ------+----------------------+---------+-------------
> > OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> > IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> > EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
> >
> >
> > Key:  Y=YES/preference    (y=second pref/implied pref)
> >       M=MAYBE/second pref (m=implied second pref)
> >       N=NO
> >       -=no explicit rejection (no comment)
> >
> > OOB | IB  | EK  | Name (alphabetical by first name)
> > ----+-----+-----+----------------------------------
> >  N  |  N  |  Y  | David Harrington
> >  -  |  y  |  -  | David Perkins
> >  N  |  Y  |  M  | Ira McDonald
> >  M  |  -  |  Y  | Juergen Schoenwaelder
> >  Y  |  M  |  -  | Kaushik Narayan
> >  Y  |  -  |  -  | Marcus Leech
> >  Y  |  -  |  M  | Martin Soukup
> >  N  |  Y  |  M  | Robert Story
> >  m  |  y  |  Y  | Sam Hartman
> >  Y  |  -  |  m  | Sharon Chisolm
> >  -  |  M  |  Y  | Tom Petch
> >  -  |  Y  |  Y  | Uri Blumenthal
> >  -  |  Y  |  M  | Wes Hardaker
> >
> 
> Has anybody changed her/his mind?
> Or does anybody want to replace a dash by a letter?
> 
> Thanks,
> 
>     Juergen
> -- 
> Juergen Quittek        quittek@netlab.nec.de       Tel: +49 
> 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 
> 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   
> http://www.netlab.nec.de
> 
> 
> 
> --On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
> 
> > ISMS members,
> >
> > There's been a lot of discussion recently on the mailing 
> list about the
> > pros and cons of different security models.  I think the 
> discussion has
> > been good, but unfortunately I don't think it's getting any 
> closer to a
> > consensus (I thank Robert for trying to draw things closer;
> > unfortunately Juergen and I have been rather busy off-line, and I
> > apologize for that).  I know that some on the mailing list have
> > expressed a preference for choosing a security protocol first, but
> > we've been tasked with choosing the architecture first, and 
> I believe
> > that is the appropriate approach.
> >
> > Anyway, I'd like to call for a consensus on the security 
> architecture.
> > As we all know, the three choices are:
> >
> > - Out of band keying (the architecture used by EUSM)
> > - In-bakd keying (the architecture used by SBSM)
> > - Encapsulation keying (the architecture used by TLSM)
> >
> > What I would like to see is WG members express which
architecture(s)
> > they prefer (you can choose more than one, but please, 
> don't choose all
> > three).  Please feel free to state your reasons for your 
> choices, but
> > in the interests of reaching consensus in a reasonable 
> timeframe, I am
> > asking that WG members please refrain from commenting on 
> other people's
> > choices unless they feel that the person has stated a fact which
is
> > obviously wrong.
> >
> > Thanks for your time,
> >
> > --Ken
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 18:50:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQYss-0005rg-WE; Tue, 26 Apr 2005 18:50:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQYsr-0005rW-Jd
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 18:50:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26820
	for <isms@ietf.org>; Tue, 26 Apr 2005 18:50:22 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQZ5L-0001Al-0c
	for isms@ietf.org; Tue, 26 Apr 2005 19:03:23 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-1.cisco.com with ESMTP; 26 Apr 2005 15:50:12 -0700
X-IronPort-AV: i="3.92,132,1112598000"; 
	d="scan'208"; a="632293134:sNHT28266800"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3QMo1L3016995;
	Tue, 26 Apr 2005 15:50:06 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 26 Apr 2005 15:50:02 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 15:50:01 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13FAF4@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVKsE4KjbtYscQrT2az0qjV23AIHAAAI3iw
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>,
	"David B Harrington" <ietfdbh@comcast.net>
X-OriginalArrivalTime: 26 Apr 2005 22:50:02.0070 (UTC)
	FILETIME=[47E43760:01C54AB2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org


> -----Original Message-----
> From: Bernard Aboba
> Sent: Tuesday, April 26, 2005 3:33 PM
> To: David B Harrington
> Cc: radiusext@ops.ietf.org; isms@ietf.org; eap@frascone.com
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
>=20
> > Why are we spending so much time discussing EAP, if the AD has told=20
> > the WG that EAP should not be used, and that the IESG is unlikely to

> > approve a solution using EAP?
> >
> > dbh
>=20
> Perhaps because the ISMS WG charter talks about RADIUS support?

Perhaps we'll revisit RADIUS later down the road, but for now let's
focus on the architecture, deciding on abstract issues like should=20
we handle AAA at SNMP instrumentation (device) level or at manager=20
application level, etc.

Khanh

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 20:54:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQap4-0004Yw-7Y; Tue, 26 Apr 2005 20:54:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQap2-0004Yr-Gs
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 20:54:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08937
	for <isms@ietf.org>; Tue, 26 Apr 2005 20:54:34 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DQb1Z-0004iz-NZ
	for isms@ietf.org; Tue, 26 Apr 2005 21:07:35 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 26 Apr 2005 17:54:26 -0700
X-IronPort-AV: i="3.92,133,1112598000"; 
	d="scan'208"; a="255085818:sNHT27913164"
Received: from kaushik-w2k03.cisco.com ([171.69.75.179])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3R0sKL0006640;
	Tue, 26 Apr 2005 17:54:21 -0700 (PDT)
Message-Id: <6.2.0.14.0.20050426174925.04ce9550@email.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 26 Apr 2005 17:54:11 -0700
To: Juergen Quittek <quittek@netlab.nec.de>
From: Kaushik Narayan <kaushik@cisco.com>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
In-Reply-To: <75F1B11B7830A96E6F82DA9E@[192.168.0.128]>
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
	<75F1B11B7830A96E6F82DA9E@[192.168.0.128]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-PMX-Version: 4.7.0.111621
X-from-outside-Cisco: [171.69.75.179]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi All,

I would like to ensure that ISMS members are making a choice on the
architecture and not on the proposals, since the proposals themselves
can work with a different architecture, for e.g. we can have EUSM work
both with the current out-of-band keying model as well as an in-band
keying model.

Here is my position

Out-of-band keying - Strongly favour. This approach introduces the
minimal amount of change of SNMPv3 USM and achieves all the
goals of ISMS.

In-band keying - Maybe,  again this position is for the architectural
approach to negotiate keys using SNMP. I still strongly oppose the
specifics of the SBSM proposal.

Encapsulation keying - Oppose.


regards,
   kaushik!


At 02:21 PM 4/26/2005, Juergen Quittek wrote:
>Dear all,
>
>We have to come to an agreement on the architecture we will use.
>Ken asked some days ago, but only one of the replies stated a clear
>position.
>
>Shall I take this as an indicator that the rest is not decided yet?
>Or does not care?  Or can we go on with the table that Robert posted?
>
>>
>>Keying|      For             | Against | Abstain
>>------+----------------------+---------+-------------
>>OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
>>IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
>>EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
>>
>>
>>Key:  Y=YES/preference    (y=second pref/implied pref)
>>       M=MAYBE/second pref (m=implied second pref)
>>       N=NO
>>       -=no explicit rejection (no comment)
>>
>>OOB | IB  | EK  | Name (alphabetical by first name)
>>----+-----+-----+----------------------------------
>>  N  |  N  |  Y  | David Harrington
>>  -  |  y  |  -  | David Perkins
>>  N  |  Y  |  M  | Ira McDonald
>>  M  |  -  |  Y  | Juergen Schoenwaelder
>>  Y  |  M  |  -  | Kaushik Narayan
>>  Y  |  -  |  -  | Marcus Leech
>>  Y  |  -  |  M  | Martin Soukup
>>  N  |  Y  |  M  | Robert Story
>>  m  |  y  |  Y  | Sam Hartman
>>  Y  |  -  |  m  | Sharon Chisolm
>>  -  |  M  |  Y  | Tom Petch
>>  -  |  Y  |  Y  | Uri Blumenthal
>>  -  |  Y  |  M  | Wes Hardaker
>
>Has anybody changed her/his mind?
>Or does anybody want to replace a dash by a letter?
>
>Thanks,
>
>    Juergen
>--
>Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
>NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
>Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
>
>
>
>--On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
>
>>ISMS members,
>>
>>There's been a lot of discussion recently on the mailing list about the
>>pros and cons of different security models.  I think the discussion has
>>been good, but unfortunately I don't think it's getting any closer to a
>>consensus (I thank Robert for trying to draw things closer;
>>unfortunately Juergen and I have been rather busy off-line, and I
>>apologize for that).  I know that some on the mailing list have
>>expressed a preference for choosing a security protocol first, but
>>we've been tasked with choosing the architecture first, and I believe
>>that is the appropriate approach.
>>
>>Anyway, I'd like to call for a consensus on the security architecture.
>>As we all know, the three choices are:
>>
>>- Out of band keying (the architecture used by EUSM)
>>- In-bakd keying (the architecture used by SBSM)
>>- Encapsulation keying (the architecture used by TLSM)
>>
>>What I would like to see is WG members express which architecture(s)
>>they prefer (you can choose more than one, but please, don't choose all
>>three).  Please feel free to state your reasons for your choices, but
>>in the interests of reaching consensus in a reasonable timeframe, I am
>>asking that WG members please refrain from commenting on other people's
>>choices unless they feel that the person has stated a fact which is
>>obviously wrong.
>>
>>Thanks for your time,
>>
>>--Ken
>>
>>_______________________________________________
>>Isms mailing list
>>Isms@lists.ietf.org
>>https://www1.ietf.org/mailman/listinfo/isms
>
>
>
>_______________________________________________
>Isms mailing list
>Isms@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Tue Apr 26 23:43:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQdSG-0003wY-Bo; Tue, 26 Apr 2005 23:43:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQdSE-0003wO-Sp
	for isms@megatron.ietf.org; Tue, 26 Apr 2005 23:43:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20808
	for <isms@ietf.org>; Tue, 26 Apr 2005 23:43:12 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQdem-0008EO-RQ
	for isms@ietf.org; Tue, 26 Apr 2005 23:56:15 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-4.cisco.com with ESMTP; 26 Apr 2005 20:43:03 -0700
Received: from gwzw2k01 (sjc-vpn2-573.cisco.com [10.21.114.61])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3R3h0b4009558;
	Tue, 26 Apr 2005 20:43:00 -0700 (PDT)
Message-Id: <200504270343.j3R3h0b4009558@sj-core-3.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>,
	"'Bernard Aboba'" <aboba@internaut.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Tue, 26 Apr 2005 20:42:54 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <3DEC199BD7489643817ECA151F7C59290107C387@pysmsx401.amr.corp.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAANgA/A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Blumenthal, Uri <mailto:uri.blumenthal@intel.com> supposedly
scribbled:

>>> It was my understanding that while EAP is between the client
>>> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP
>>> method* that runs on top of EAP is between the client and RADIUS
>>> server.
>> 
>> No. Can we just _get it_ once and for all?  AAA & EAP are
_different_
>> and _separate_ things: there is no part of EAP that is "between"
the
>> EAP peer and any AAA entity.
> 
> What about EAP methods that run between the EAP client and EAP
server?
> Are you saying that EAP _method_ does not terminate in an EAP
server,
> or that EAP server is not usually [within and part of] a AAA
server?

No, but this is an implementation detail: it is by no means
necessary to have _any_ AAA infrastructure to deploy EAP.  AAA makes
it more convenient, scale better, etc., but it's not necessary, nor
is EAP "part of" AAA.

> "EAP server" is what "eap peer" and "aaa" share.  
> Oh and we _are_ talking EAPv2, right?

I don't know what that is.

> 
> 
>>> This tunnel created by EAP method can be considered as "trust
>>> between the client and AAA",
>> 
>> See above.
> 
> See above. I consider EAP server running inside AAA server. If
others
> (besides Glen and Bernard) on this list disagree with this
perception
> - I invite them to speak up please.  
> 
> 
>>> and RADIUS between NAS and AAA (however it is
>>> accomplished) is "trust between NAS and AAA".
>>> 
>>> And yes, many find convenient to connect authorization decision
to
>>> some extra information about the supplicant - such as its
posture
>>> evaluation (Cisco NAC, Microsoft NAP, etc). Such information
would
>>> naturally be carried in TLVs as part of EAP inner method
exchange.
>> 
>> Or more rationally (gasp!) in a subsequent _authorization_
protocol
>> exchange.
> 
> Kindly explain how "authorization" doesn't include trust of the
> authorizing entity. 

I may not trust the government of the United States, but it has
authorized me (through the issuance of a passport) to leave the
country and return.  

> Also, it may be news for you - but [at least
> some] people want authentication combined with authorization: i.e.
if
> I get a set of keys, it means that (a) the AAA authenticated me
OK,
> _and_ (b) that the server implicitly authorized me to communicate
> with the given NAS.  

It's not news to me at all -- it's the same old RADIUS story.  
   
> 
> That authorization is dependent on host posture evaluation. I
thought
> it was Cisco that proposed it in their NAC architecture? Perhaps
you
> can/should shed some light on this?  

I thought this was a standards discussion; if you want to talk about
NAC (or any other proprietary Cisco stuff), I suggest that you talk
to your account manager -- I'm sure that he or she would love to
extol its wonders.  

> 
> 
>>> Yes it seems to go way beyond the original purpose of EAP, but
then
>>> it does seem to address the today's need.
>> 
>> If one has a sore toe, shooting oneself in the foot may seem to
>> satisfy "today's need"; in the long run, however, it will
probably
>> turn out to be counterproductive.
> 
> I'm simply describing what I perceive as today's reality. You may
> intensely dislike it - it's your free choice. Looks like the
market
> is moving the above-described way.  

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 27 01:43:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQfKJ-0003Xf-5S; Wed, 27 Apr 2005 01:43:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQfKI-0003XX-9t
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 01:43:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27940
	for <isms@ietf.org>; Wed, 27 Apr 2005 01:43:09 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQfWs-0001uO-DK
	for isms@ietf.org; Wed, 27 Apr 2005 01:56:11 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DQfKF-000OPD-RQ; Wed, 27 Apr 2005 01:43:07 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3R5h5605097;
	Tue, 26 Apr 2005 22:43:06 -0700
Date: Tue, 26 Apr 2005 22:43:05 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: "Glen Zorn (gwz)" <gwz@cisco.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
In-Reply-To: <200504270343.j3R3h0b4009558@sj-core-3.cisco.com>
Message-ID: <Pine.LNX.4.56.0504262232570.4468@internaut.com>
References: <200504270343.j3R3h0b4009558@sj-core-3.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: isms@ietf.org, radiusext@ops.ietf.org, eap@frascone.com
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> "EAP server" is what "eap peer" and "aaa" share.

An EAP server can exist on the authenticator when there is  no AAA
server present.  It is a distinct entity from the EAP peer.  It is not
"shared" between the EAP peer and AAA server.

> Oh and we _are_ talking EAPv2, right?

The only version of EAP that I'm familiar with is defined in RFC 3748.

Maybe this entire discussion has been about some *other* version of EAP?




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 27 10:24:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQnSa-00067z-6R; Wed, 27 Apr 2005 10:24:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQnSY-00067H-9x
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 10:24:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19489
	for <isms@ietf.org>; Wed, 27 Apr 2005 10:24:12 -0400 (EDT)
Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQnf5-0005or-Op
	for isms@ietf.org; Wed, 27 Apr 2005 10:37:20 -0400
Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124])
	by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j3REO3ZC004141
	for <isms@ietf.org>; Wed, 27 Apr 2005 10:24:03 -0400 (EDT)
Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan
	Messaging Security Suite; Wed, 27 Apr 2005 10:23:59 -0400
Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; 
	Wed, 27 Apr 2005 10:23:58 -0400
Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with
	Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Apr 2005 10:23:19 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 27 Apr 2005 10:23:16 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032300@MAANDMBX2.ets.enterasys.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAANgA/AAB4/mtA=
From: "Nelson, David" <dnelson@enterasys.com>
To: <gwz@cisco.com>
X-OriginalArrivalTime: 27 Apr 2005 14:23:19.0014 (UTC)
	FILETIME=[A8ABC860:01C54B34]
X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8
X-pstn-levels: (C:84.0661 M:98.6627 P:95.9108 R:95.9108 S:42.1923 )
X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13
X-pstn-addresses: from <dnelson@enterasys.com> forward (org good) 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org


Glen Zorn writes...

> I may not trust the government of the United States, but it has
> authorized me (through the issuance of a passport) to leave the
> country and return.

I'm not sure this is an apt example of your point.  I rather suspect
that your distrust of the Federal government extends to areas other than
whether or not the agency that issued you a passport has the authority
to do so. :-)

In terms of the trust needed for enforcement of authorization, in your
example it is the trust relationship that various customs agents have
with the US government (among others) that allows them to validate your
passport and grant you passage.

In general, I think that concept of authorization without any form of
trust relationship is pretty useless.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 27 11:52:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQoqK-0006bn-JT; Wed, 27 Apr 2005 11:52:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQoqJ-0006be-KX
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 11:52:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26043
	for <isms@ietf.org>; Wed, 27 Apr 2005 11:52:49 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com ([130.76.96.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQp2w-0007jr-R7
	for isms@ietf.org; Wed, 27 Apr 2005 12:05:58 -0400
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id
	KAA26753; Wed, 27 Apr 2005 10:52:35 -0500 (CDT)
Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id
	j3RFqYm05579; Wed, 27 Apr 2005 10:52:34 -0500 (CDT)
Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by
	XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Apr 2005 08:52:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Wed, 27 Apr 2005 08:52:32 -0700
Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDE3B@xch-nw-09.nw.nos.boeing.com>
Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Thread-Index: AcVKpmk0MFirWMn7SVOPG5M3iEzSfQACv5MQACPDoQA=
From: "Fleischman, Eric" <eric.fleischman@boeing.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>, <isms@ietf.org>
X-OriginalArrivalTime: 27 Apr 2005 15:52:33.0110 (UTC)
	FILETIME=[1FF5FF60:01C54B41]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

My view:
OOB -- Depends on specific approach but isn't attractive in the general
case =20
IB  -- yes, my preference
EK  -- Depends on approach

--Eric

> -----Original Message-----
> From: isms-bounces@lists.ietf.org
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek
> Sent: Tuesday, April 26, 2005 5:22 PM
> To: isms@ietf.org
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
>=20
> Dear all,
>=20
> We have to come to an agreement on the architecture we will use. Ken=20
> asked some days ago, but only one of the replies stated a clear=20
> position.
>=20
> Shall I take this as an indicator that the rest is not decided yet? Or

> does not care?  Or can we go on with the table that Robert
posted?
>=20
> >
> > Keying|      For             | Against | Abstain
> > ------+----------------------+---------+-------------
> > OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> > IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> > EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
> >
> >
> > Key:  Y=3DYES/preference    (y=3Dsecond pref/implied pref)
> >       M=3DMAYBE/second pref (m=3Dimplied second pref)
> >       N=3DNO
> >       -=3Dno explicit rejection (no comment)
> >
> > OOB | IB  | EK  | Name (alphabetical by first name)
> > ----+-----+-----+----------------------------------
> >  N  |  N  |  Y  | David Harrington
> >  -  |  y  |  -  | David Perkins
> >  N  |  Y  |  M  | Ira McDonald
> >  M  |  -  |  Y  | Juergen Schoenwaelder
> >  Y  |  M  |  -  | Kaushik Narayan
> >  Y  |  -  |  -  | Marcus Leech
> >  Y  |  -  |  M  | Martin Soukup
> >  N  |  Y  |  M  | Robert Story
> >  m  |  y  |  Y  | Sam Hartman
> >  Y  |  -  |  m  | Sharon Chisolm
> >  -  |  M  |  Y  | Tom Petch
> >  -  |  Y  |  Y  | Uri Blumenthal
> >  -  |  Y  |  M  | Wes Hardaker
> >
>=20
> Has anybody changed her/his mind?
> Or does anybody want to replace a dash by a letter?
>=20
> Thanks,
>=20
>     Juergen
> --=20
> Juergen Quittek        quittek@netlab.nec.de       Tel: +49=20
> 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49=20
> 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany  =20
> http://www.netlab.nec.de
>=20
>=20
>=20
> --On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
>=20
> > ISMS members,
> >
> > There's been a lot of discussion recently on the mailing
> list about the
> > pros and cons of different security models.  I think the
> discussion has
> > been good, but unfortunately I don't think it's getting any
> closer to a
> > consensus (I thank Robert for trying to draw things closer;=20
> > unfortunately Juergen and I have been rather busy off-line, and I=20
> > apologize for that).  I know that some on the mailing list have=20
> > expressed a preference for choosing a security protocol first, but=20
> > we've been tasked with choosing the architecture first, and
> I believe
> > that is the appropriate approach.
> >
> > Anyway, I'd like to call for a consensus on the security
> architecture.
> > As we all know, the three choices are:
> >
> > - Out of band keying (the architecture used by EUSM)
> > - In-bakd keying (the architecture used by SBSM)
> > - Encapsulation keying (the architecture used by TLSM)
> >
> > What I would like to see is WG members express which
architecture(s)
> > they prefer (you can choose more than one, but please,
> don't choose all
> > three).  Please feel free to state your reasons for your
> choices, but
> > in the interests of reaching consensus in a reasonable
> timeframe, I am
> > asking that WG members please refrain from commenting on
> other people's
> > choices unless they feel that the person has stated a fact which
is
> > obviously wrong.
> >
> > Thanks for your time,
> >
> > --Ken
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms
>=20
>=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms
>=20



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 27 12:15:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQp7K-0000dL-Fz; Wed, 27 Apr 2005 12:10:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQp7I-0000d9-Gq
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 12:10:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28106
	for <isms@ietf.org>; Wed, 27 Apr 2005 12:10:21 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQpJs-0008E4-Ub
	for isms@ietf.org; Wed, 27 Apr 2005 12:23:31 -0400
Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1
	2004/09/17 17:50:56 root Exp $) with ESMTP id j3RG91jI020678; 
	Wed, 27 Apr 2005 16:09:01 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com
	[132.233.42.129])
	by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2
	2004/09/17 18:05:01 root Exp $) with SMTP id j3RG8s01019590; 
	Wed, 27 Apr 2005 16:08:59 GMT
Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156])
	by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042709085915472 ; Wed, 27 Apr 2005 09:08:59 -0700
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by
	fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Apr 2005 09:08:55 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Apr 2005 09:08:53 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Apr 2005 12:08:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 27 Apr 2005 12:08:11 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929010C816A@pysmsx401.amr.corp.intel.com>
Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party
Thread-Index: AcVK7ACUotYD3bjETgycjROMFLjGYQAVrEWg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: "Bernard Aboba" <aboba@internaut.com>, "Glen Zorn \(gwz\)" <gwz@cisco.com>
X-OriginalArrivalTime: 27 Apr 2005 16:08:38.0753 (UTC)
	FILETIME=[5F876D10:01C54B43]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: quoted-printable
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>> "EAP server" is what "eap peer" and "aaa" share.
>
> An EAP server can exist on the authenticator when there is  no AAA
> server present.  It is a distinct entity from the EAP peer.  It is not
> "shared" between the EAP peer and AAA server.

In theory EAP server is a distinct entity and can be anywhere, in
practice it's a part of AAA most of the time. Why are we arguing about
this?


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 27 17:26:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQu2x-0003Eu-CU; Wed, 27 Apr 2005 17:26:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQu2v-0003Em-HP
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 17:26:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09731
	for <isms@ietf.org>; Wed, 27 Apr 2005 17:26:11 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQuFd-0002xm-UQ
	for isms@ietf.org; Wed, 27 Apr 2005 17:39:23 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-4.cisco.com with ESMTP; 27 Apr 2005 14:26:03 -0700
Received: from gwzw2k01 (rtp-vpn2-181.cisco.com [10.82.240.181])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3RLPxb4023713;
	Wed, 27 Apr 2005 14:26:00 -0700 (PDT)
Message-Id: <200504272126.j3RLPxb4023713@sj-core-3.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Bernard Aboba'" <aboba@internaut.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 27 Apr 2005 14:25:53 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <Pine.LNX.4.56.0504262232570.4468@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVK7az+B8gHtO7zTr+ZdPa5n+Z1wAAAjLUQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org, radiusext@ops.ietf.org, eap@frascone.com
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Bernard Aboba <mailto:aboba@internaut.com> supposedly scribbled:

>> "EAP server" is what "eap peer" and "aaa" share.
> 
> An EAP server can exist on the authenticator when there is  no AAA
> server present.  

I'd actually go a bit further and claim that the distinction between
the authenticator and the EAP "server" is one of convenience & that
they are logically the same entity.

> It is a distinct entity from the EAP peer.  It is
> not "shared" between the EAP peer and AAA server.  
> 
>> Oh and we _are_ talking EAPv2, right?
> 
> The only version of EAP that I'm familiar with is defined in RFC
3748.
> 
> Maybe this entire discussion has been about some *other* version
of
> EAP? 

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 27 17:47:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQuN7-0006uP-7h; Wed, 27 Apr 2005 17:47:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQuN5-0006t7-L7
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 17:47:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10773
	for <isms@ietf.org>; Wed, 27 Apr 2005 17:47:01 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQuZo-0003SZ-81
	for isms@ietf.org; Wed, 27 Apr 2005 18:00:13 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-5.cisco.com with ESMTP; 27 Apr 2005 14:46:53 -0700
Received: from gwzw2k01 (rtp-vpn2-181.cisco.com [10.82.240.181])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3RLkipR011477;
	Wed, 27 Apr 2005 14:46:45 -0700 (PDT)
Message-Id: <200504272146.j3RLkipR011477@sj-core-4.cisco.com>
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "'Blumenthal, Uri'" <uri.blumenthal@intel.com>,
	"'Bernard Aboba'" <aboba@internaut.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 27 Apr 2005 14:46:38 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929010C816A@pysmsx401.amr.corp.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Thread-Index: AcVK7ACUotYD3bjETgycjROMFLjGYQAVrEWgAAsaRnA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: gwz@cisco.com
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Blumenthal, Uri <mailto:uri.blumenthal@intel.com> supposedly
scribbled:

>>> "EAP server" is what "eap peer" and "aaa" share.
>> 
>> An EAP server can exist on the authenticator when there is  no
AAA
>> server present.  It is a distinct entity from the EAP peer.  It
is
>> not "shared" between the EAP peer and AAA server.
> 
> In theory EAP server is a distinct entity and can be anywhere, in
> practice it's a part of AAA most of the time. Why are we arguing
> about this?  

I thought we were talking about architecture; and further,
discussing components which might or might not be utilized in that
architecture.  Maybe it's just me, but I think that it's a good idea
to understand how those components actually work (as opposed to how
we might wish or imagine they work, or the direction in which
marketeers might be pushing them).  If a building architect thought
that a brick was part of a girder, he would design a pretty strange
building and  misconceptions in networking can easily lead to
similar results.  For example, there was a recent thread on a
different list in which someone was worried about security problems
if a 4th party (!) was introduced into an EAP conversation.  There
are not 3 or 4 or 17 parties in an EAP exchange, there are exactly
2; there are also (logically) 2 parties in a RADIUS exchange, and
those sets are disjoint.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Wed Apr 27 21:28:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQxpH-0003ek-UK; Wed, 27 Apr 2005 21:28:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQxpF-0003ec-7G
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 21:28:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28182
	for <isms@ietf.org>; Wed, 27 Apr 2005 21:28:19 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQy1y-0000x3-AB
	for isms@ietf.org; Wed, 27 Apr 2005 21:41:32 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3S1S0J25667; Wed, 27 Apr 2005 21:28:00 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3S1Rkd00108; Wed, 27 Apr 2005 21:27:46 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RPZ53>; Wed, 27 Apr 2005 21:27:33 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9BE5@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Fleischman, Eric'" <eric.fleischman@boeing.com>, "'Juergen Quittek'"
	<quittek@netlab.nec.de>, "'isms@ietf.org'" <isms@ietf.org>
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Wed, 27 Apr 2005 21:27:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1707391932=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1707391932==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54B91.703BB527"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54B91.703BB527
Content-Type: text/plain

Update my row please:

OOBK - yes
IBK - no
EK - no

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric
> Sent: April 27, 2005 11:53 AM
> To: Juergen Quittek; isms@ietf.org
> Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> 
> My view:
> OOB -- Depends on specific approach but isn't attractive in 
> the general case  
> IB  -- yes, my preference
> EK  -- Depends on approach
> 
> --Eric
> 
> > -----Original Message-----
> > From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] 
> > On Behalf Of Juergen Quittek
> > Sent: Tuesday, April 26, 2005 5:22 PM
> > To: isms@ietf.org
> > Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> > 
> > Dear all,
> > 
> > We have to come to an agreement on the architecture we will use. Ken
> > asked some days ago, but only one of the replies stated a clear 
> > position.
> > 
> > Shall I take this as an indicator that the rest is not 
> decided yet? Or
> 
> > does not care?  Or can we go on with the table that Robert
> posted?
> > 
> > >
> > > Keying|      For             | Against | Abstain
> > > ------+----------------------+---------+-------------
> > > OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> > > IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> > > EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
> > >
> > >
> > > Key:  Y=YES/preference    (y=second pref/implied pref)
> > >       M=MAYBE/second pref (m=implied second pref)
> > >       N=NO
> > >       -=no explicit rejection (no comment)
> > >
> > > OOB | IB  | EK  | Name (alphabetical by first name)
> > > ----+-----+-----+----------------------------------
> > >  N  |  N  |  Y  | David Harrington
> > >  -  |  y  |  -  | David Perkins
> > >  N  |  Y  |  M  | Ira McDonald
> > >  M  |  -  |  Y  | Juergen Schoenwaelder
> > >  Y  |  M  |  -  | Kaushik Narayan
> > >  Y  |  -  |  -  | Marcus Leech
> > >  Y  |  -  |  M  | Martin Soukup
> > >  N  |  Y  |  M  | Robert Story
> > >  m  |  y  |  Y  | Sam Hartman
> > >  Y  |  -  |  m  | Sharon Chisolm
> > >  -  |  M  |  Y  | Tom Petch
> > >  -  |  Y  |  Y  | Uri Blumenthal
> > >  -  |  Y  |  M  | Wes Hardaker
> > >
> > 
> > Has anybody changed her/his mind?
> > Or does anybody want to replace a dash by a letter?
> > 
> > Thanks,
> > 
> >     Juergen
> > -- 
> > Juergen Quittek        quittek@netlab.nec.de       Tel: +49 
> > 6221 90511-15
> > NEC Europe Ltd.,       Network Laboratories        Fax: +49 
> > 6221 90511-55
> > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   
> > http://www.netlab.nec.de
> > 
> > 
> > 
> > --On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
> > 
> > > ISMS members,
> > >
> > > There's been a lot of discussion recently on the mailing
> > list about the
> > > pros and cons of different security models.  I think the
> > discussion has
> > > been good, but unfortunately I don't think it's getting any
> > closer to a
> > > consensus (I thank Robert for trying to draw things closer;
> > > unfortunately Juergen and I have been rather busy off-line, and I 
> > > apologize for that).  I know that some on the mailing list have 
> > > expressed a preference for choosing a security protocol 
> first, but 
> > > we've been tasked with choosing the architecture first, and
> > I believe
> > > that is the appropriate approach.
> > >
> > > Anyway, I'd like to call for a consensus on the security
> > architecture.
> > > As we all know, the three choices are:
> > >
> > > - Out of band keying (the architecture used by EUSM)
> > > - In-bakd keying (the architecture used by SBSM)
> > > - Encapsulation keying (the architecture used by TLSM)
> > >
> > > What I would like to see is WG members express which
> architecture(s)
> > > they prefer (you can choose more than one, but please,
> > don't choose all
> > > three).  Please feel free to state your reasons for your
> > choices, but
> > > in the interests of reaching consensus in a reasonable
> > timeframe, I am
> > > asking that WG members please refrain from commenting on
> > other people's
> > > choices unless they feel that the person has stated a fact which
> is
> > > obviously wrong.
> > >
> > > Thanks for your time,
> > >
> > > --Ken
> > >
> > > _______________________________________________
> > > Isms mailing list
> > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms
> > 
> > 
> > 
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms
> > 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

------_=_NextPart_001_01C54B91.703BB527
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Update my row please:</FONT>
</P>

<P><FONT SIZE=3D2>OOBK - yes</FONT>
<BR><FONT SIZE=3D2>IBK - no</FONT>
<BR><FONT SIZE=3D2>EK - no</FONT>
</P>

<P><FONT SIZE=3D2>Martin.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Fleischman, Eric</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 27, 2005 11:53 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Juergen Quittek; isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS =
Architecture</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My view:</FONT>
<BR><FONT SIZE=3D2>&gt; OOB -- Depends on specific approach but isn't =
attractive in </FONT>
<BR><FONT SIZE=3D2>&gt; the general case&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; IB&nbsp; -- yes, my preference</FONT>
<BR><FONT SIZE=3D2>&gt; EK&nbsp; -- Depends on approach</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --Eric</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On Behalf Of Juergen Quittek</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, April 26, 2005 5:22 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: isms@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: [Isms] CALL FOR CONSENSUS: =
ISMS Architecture</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dear all,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We have to come to an agreement on the =
architecture we will use. Ken</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; asked some days ago, but only one of the =
replies stated a clear </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; position.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Shall I take this as an indicator that the =
rest is not </FONT>
<BR><FONT SIZE=3D2>&gt; decided yet? Or</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; does not care?&nbsp; Or can we go on with =
the table that Robert</FONT>
<BR><FONT SIZE=3D2>&gt; posted?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Keying|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
For&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; | Against | Abstain</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
------+----------------------+---------+-------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; OOB&nbsp;&nbsp; |&nbsp; 6 (4 Yes, 2 =
Maybes) |&nbsp; 3 No&nbsp;&nbsp; | 4 no comment</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; IB&nbsp;&nbsp;&nbsp; |&nbsp; 8 (6 =
Yes, 2 Maybe)&nbsp; |&nbsp; 1 No&nbsp;&nbsp; | 4 no comment</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; EK&nbsp;&nbsp;&nbsp; | 10 (5 Yes, 5 =
Maybe)&nbsp; |&nbsp; 0 No&nbsp;&nbsp; | 3 no comment</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Key:&nbsp; =
Y=3DYES/preference&nbsp;&nbsp;&nbsp; (y=3Dsecond pref/implied =
pref)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
M=3DMAYBE/second pref (m=3Dimplied second pref)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
N=3DNO</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-=3Dno explicit rejection (no comment)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; OOB | IB&nbsp; | EK&nbsp; | Name =
(alphabetical by first name)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
----+-----+-----+----------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; N&nbsp; |&nbsp; N&nbsp; |&nbsp; =
Y&nbsp; | David Harrington</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; -&nbsp; |&nbsp; y&nbsp; |&nbsp; =
-&nbsp; | David Perkins</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; N&nbsp; |&nbsp; Y&nbsp; |&nbsp; =
M&nbsp; | Ira McDonald</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; M&nbsp; |&nbsp; -&nbsp; |&nbsp; =
Y&nbsp; | Juergen Schoenwaelder</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; Y&nbsp; |&nbsp; M&nbsp; |&nbsp; =
-&nbsp; | Kaushik Narayan</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; Y&nbsp; |&nbsp; -&nbsp; |&nbsp; =
-&nbsp; | Marcus Leech</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; Y&nbsp; |&nbsp; -&nbsp; |&nbsp; =
M&nbsp; | Martin Soukup</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; N&nbsp; |&nbsp; Y&nbsp; |&nbsp; =
M&nbsp; | Robert Story</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; m&nbsp; |&nbsp; y&nbsp; |&nbsp; =
Y&nbsp; | Sam Hartman</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; Y&nbsp; |&nbsp; -&nbsp; |&nbsp; =
m&nbsp; | Sharon Chisolm</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; -&nbsp; |&nbsp; M&nbsp; |&nbsp; =
Y&nbsp; | Tom Petch</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; -&nbsp; |&nbsp; Y&nbsp; |&nbsp; =
Y&nbsp; | Uri Blumenthal</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; -&nbsp; |&nbsp; Y&nbsp; |&nbsp; =
M&nbsp; | Wes Hardaker</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Has anybody changed her/his mind?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Or does anybody want to replace a dash by =
a letter?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Juergen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Juergen =
Quittek&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
quittek@netlab.nec.de&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel: +49 =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 6221 90511-15</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; NEC Europe =
Ltd.,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Network =
Laboratories&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: +49 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 6221 90511-55</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Kurfuersten-Anlage 36, 69115 Heidelberg, =
Germany&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"http://www.netlab.nec.de" =
TARGET=3D"_blank">http://www.netlab.nec.de</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --On 4/21/2005 4:17 PM -0400 Ken Hornstein =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ISMS members,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; There's been a lot of discussion =
recently on the mailing</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; list about the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; pros and cons of different security =
models.&nbsp; I think the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; discussion has</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; been good, but unfortunately I don't =
think it's getting any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; closer to a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; consensus (I thank Robert for trying =
to draw things closer;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; unfortunately Juergen and I have been =
rather busy off-line, and I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; apologize for that).&nbsp; I know =
that some on the mailing list have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; expressed a preference for choosing a =
security protocol </FONT>
<BR><FONT SIZE=3D2>&gt; first, but </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; we've been tasked with choosing the =
architecture first, and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I believe</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that is the appropriate =
approach.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Anyway, I'd like to call for a =
consensus on the security</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; architecture.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; As we all know, the three choices =
are:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; - Out of band keying (the =
architecture used by EUSM)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; - In-bakd keying (the architecture =
used by SBSM)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; - Encapsulation keying (the =
architecture used by TLSM)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; What I would like to see is WG =
members express which</FONT>
<BR><FONT SIZE=3D2>&gt; architecture(s)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; they prefer (you can choose more than =
one, but please,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; don't choose all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; three).&nbsp; Please feel free to =
state your reasons for your</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; choices, but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; in the interests of reaching =
consensus in a reasonable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; timeframe, I am</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; asking that WG members please refrain =
from commenting on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; other people's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; choices unless they feel that the =
person has stated a fact which</FONT>
<BR><FONT SIZE=3D2>&gt; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; obviously wrong.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Thanks for your time,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; --Ken</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Isms@lists.ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Isms@lists.ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54B91.703BB527--


--===============1707391932==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============1707391932==--




From isms-bounces@lists.ietf.org Wed Apr 27 21:38:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DQxzB-00056x-1f; Wed, 27 Apr 2005 21:38:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DQxzA-00055x-8d
	for isms@megatron.ietf.org; Wed, 27 Apr 2005 21:38:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28725
	for <isms@ietf.org>; Wed, 27 Apr 2005 21:38:33 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQyBs-0001Dc-Ll
	for isms@ietf.org; Wed, 27 Apr 2005 21:51:47 -0400
Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j3S1cJJ26528; Wed, 27 Apr 2005 21:38:19 -0400 (EDT)
Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61])
	by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3S1cVd01584; Wed, 27 Apr 2005 21:38:31 -0400 (EDT)
Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HQ3RPZ66>; Wed, 27 Apr 2005 21:38:18 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5030B9BEB@zcarhxm2.corp.nortel.com>
From: "Martin Soukup" <msoukup@nortel.com>
To: "'Bernard Aboba'" <aboba@internaut.com>, "'David B Harrington'"
	<ietfdbh@comcast.net>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Date: Wed, 27 Apr 2005 21:38:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: "'radiusext@ops.ietf.org'" <radiusext@ops.ietf.org>,
	"'eap@frascone.com'" <eap@frascone.com>, "'isms@ietf.org'" <isms@ietf.org>
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0008067605=="
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0008067605==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C54B92.F2E350CC"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C54B92.F2E350CC
Content-Type: text/plain

I believe the AD's direction on EAP was based on certain uses of EAP as
might have been understood earlier in the current discussions. Perhaps Sam
can comment, but I believe that the use of EAP for the exchange of keying
information for authentication and privacy is fully within the applicability
of EAP as stated (e.g. as it is used over RADIUS for 802.1x and WPA key
distribution).

Martin. 

> -----Original Message-----
> From: isms-bounces@lists.ietf.org 
> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Bernard Aboba
> Sent: April 26, 2005 6:33 PM
> To: David B Harrington
> Cc: radiusext@ops.ietf.org; isms@ietf.org; eap@frascone.com
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> 
> > Why are we spending so much time discussing EAP, if the AD has told 
> > the WG that EAP should not be used, and that the IESG is 
> unlikely to 
> > approve a solution using EAP?
> >
> > dbh
> 
> Perhaps because the ISMS WG charter talks about RADIUS support?
> 
> Just a thought :)
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 

------_=_NextPart_001_01C54B92.F2E350CC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [eap] RE: [Isms] RADIUS is not a trusted third party</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I believe the AD's direction on EAP was based on =
certain uses of EAP as might have been understood earlier in the =
current discussions. Perhaps Sam can comment, but I believe that the =
use of EAP for the exchange of keying information for authentication =
and privacy is fully within the applicability of EAP as stated (e.g. as =
it is used over RADIUS for 802.1x and WPA key distribution).</FONT></P>

<P><FONT SIZE=3D2>Martin. </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: isms-bounces@lists.ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:isms-bounces@lists.ietf.org">mailto:isms-bounces@lists.ie=
tf.org</A>] On Behalf Of Bernard Aboba</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: April 26, 2005 6:33 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: David B Harrington</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: radiusext@ops.ietf.org; isms@ietf.org; =
eap@frascone.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [eap] RE: [Isms] RADIUS is not a =
trusted third party</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Why are we spending so much time =
discussing EAP, if the AD has told </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the WG that EAP should not be used, and =
that the IESG is </FONT>
<BR><FONT SIZE=3D2>&gt; unlikely to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; approve a solution using EAP?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; dbh</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Perhaps because the ISMS WG charter talks about =
RADIUS support?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Just a thought :)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Isms mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Isms@lists.ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/isms" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/isms</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54B92.F2E350CC--


--===============0008067605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

--===============0008067605==--




From isms-bounces@lists.ietf.org Thu Apr 28 01:33:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DR1er-0006hA-0I; Thu, 28 Apr 2005 01:33:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DR1eo-0006h2-VS
	for isms@megatron.ietf.org; Thu, 28 Apr 2005 01:33:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17003
	for <isms@ietf.org>; Thu, 28 Apr 2005 01:33:49 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR1rb-0008UH-BT
	for isms@ietf.org; Thu, 28 Apr 2005 01:47:04 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DR1eW-0004pX-H6; Thu, 28 Apr 2005 01:33:32 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3S5XUi29198;
	Wed, 27 Apr 2005 22:33:31 -0700
Date: Wed, 27 Apr 2005 22:33:30 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: isms@ietf.org
In-Reply-To: <200504272126.j3RLPxb4023713@sj-core-3.cisco.com>
Message-ID: <Pine.LNX.4.56.0504272227390.25161@internaut.com>
References: <200504272126.j3RLPxb4023713@sj-core-3.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: Jari Arkko <jari.arkko@piuha.net>
Subject: [Isms] Cross posting to the EAP WG mailing list
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Over the last few weeks, a large number of messages relating to ISMS have
been cross-posted to the EAP WG mailing list.

At present, the EAP WG has a limited number of work items left on its
plate, and the group needs to focus on that.

In order to avoid continued disruption, I would like to request that the
cross posting cease.  If there is a need for the EAP WG to assist ISMS WG
by reviewing a specific document, let us know.

Bernard Aboba
EAP WG Co-Chair


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 28 06:28:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DR6GM-00082z-Ee; Thu, 28 Apr 2005 06:28:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DR6GK-00082s-QA
	for isms@megatron.ietf.org; Thu, 28 Apr 2005 06:28:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00304
	for <isms@ietf.org>; Thu, 28 Apr 2005 06:28:50 -0400 (EDT)
Received: from adsl-multi-1-c29-p057.vtx.ch ([212.147.29.57]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR6TA-0003Rc-4Y
	for isms@ietf.org; Thu, 28 Apr 2005 06:42:09 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 08909E0063; Thu, 28 Apr 2005 06:28:43 -0400 (EDT)
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Thu, 28 Apr 2005 06:28:43 -0400
In-Reply-To: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil> (Ken
	Hornstein's message of "Thu, 21 Apr 2005 16:17:32 -0400")
Message-ID: <tsl64y7p544.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Preference against OOBK.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 28 10:01:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DR9a0-0002kC-5f; Thu, 28 Apr 2005 10:01:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9Zy-0002k7-Bg
	for isms@megatron.ietf.org; Thu, 28 Apr 2005 10:01:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16932
	for <isms@ietf.org>; Thu, 28 Apr 2005 10:01:20 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR9mp-0003d3-Js
	for isms@ietf.org; Thu, 28 Apr 2005 10:14:40 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44)
	id 1DR9Zv-000FzP-Ot; Thu, 28 Apr 2005 10:01:19 -0400
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id j3SE1Is28536;
	Thu, 28 Apr 2005 07:01:18 -0700
Date: Thu, 28 Apr 2005 07:01:18 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: isms@ietf.org
In-Reply-To: <Pine.LNX.4.56.0504272227390.25161@internaut.com>
Message-ID: <Pine.LNX.4.56.0504280659270.26739@internaut.com>
References: <200504272126.j3RLPxb4023713@sj-core-3.cisco.com>
	<Pine.LNX.4.56.0504272227390.25161@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: Jari Arkko <jari.arkko@piuha.net>
Subject: [Isms] Re: Cross posting to the EAP WG mailing list
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

To be clear, the issue is that the cross posted messages did not relate to
EAP, but to AAA.  Issues specifically relating to EAP are fair game on the
EAP WG mailing list, particularly if they relate to specific documents
that the WG has worked on or is working on (such as RFC 3748 or the EAP
Key Management Framework).

On Wed, 27 Apr 2005, Bernard Aboba wrote:

> Over the last few weeks, a large number of messages relating to ISMS have
> been cross-posted to the EAP WG mailing list.
>
> At present, the EAP WG has a limited number of work items left on its
> plate, and the group needs to focus on that.
>
> In order to avoid continued disruption, I would like to request that the
> cross posting cease.  If there is a need for the EAP WG to assist ISMS WG
> by reviewing a specific document, let us know.
>
> Bernard Aboba
> EAP WG Co-Chair
>
>

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 28 10:07:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DR9fp-0003qq-Ss; Thu, 28 Apr 2005 10:07:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9fn-0003mD-R0
	for isms@megatron.ietf.org; Thu, 28 Apr 2005 10:07:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17677
	for <isms@ietf.org>; Thu, 28 Apr 2005 10:07:21 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.ca.nortel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR9se-0003s6-K2
	for isms@ietf.org; Thu, 28 Apr 2005 10:20:41 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j3SE6ZJ27390; Thu, 28 Apr 2005 10:06:35 -0400 (EDT)
Received: from nortel.com (wcary0w4.ca.nortel.com [47.129.148.152]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id 29WL4LWQ; Thu, 28 Apr 2005 10:06:53 -0400
Message-ID: <4270EDFC.1060703@nortel.com>
Date: Thu, 28 Apr 2005 10:06:52 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Marcus Leech <mleech@nortel.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
In-Reply-To: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

For OOBK, with EBK as a second choice.

-- 
Marcus Leech                            Mail:   Dept 1A12, M/S: 04352P16
Security Standards Advisor        Phone: (ESN) 393-9145  +1 613 763 9145
Strategic Standards, CTO Office
Nortel Networks                          mleech@nortel.com



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 28 11:49:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRBGz-0001m6-80; Thu, 28 Apr 2005 11:49:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRBGx-0001lw-2t
	for isms@megatron.ietf.org; Thu, 28 Apr 2005 11:49:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28140
	for <isms@ietf.org>; Thu, 28 Apr 2005 11:49:48 -0400 (EDT)
Received: from ranger.systems.pipex.net ([62.241.162.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRBTo-00004w-VM
	for isms@ietf.org; Thu, 28 Apr 2005 12:03:10 -0400
Received: from pc6 (1Cust184.tnt103.lnd4.gbr.da.uu.net [213.116.54.184])
	by ranger.systems.pipex.net (Postfix) with SMTP id 0A1E3E000148;
	Thu, 28 Apr 2005 16:49:35 +0100 (BST)
Message-ID: <050201c54c00$f9ee9280$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <isms@ietf.org>, "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
References: <200504262037.j3QKbsTL016489@ginger.cmf.nrl.navy.mil>
Subject: Re: [Isms] securityName in Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Thu, 28 Apr 2005 15:44:41 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 2.9 (++)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

<inline>
Tom Petch

----- Original Message -----
From: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
To: <isms@ietf.org>
Sent: Tuesday, April 26, 2005 10:37 PM
Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party


> >But this id is not used in the actual session between manager and agent
(because
> >that means a change of human requires a change in every agent)
>
> Ah.  This of course depends on the security infrastructure that you use.
> I can think of several that do not require that (only one change is required
> in one place).
>
> I think if an operator wants to the system that you describe, then
> that's fine (and I don't think anything that we've discussed will
> prevent that), but from what I understood plenty of operators want to
> use their "user" identities directly with SNMP.

I would like to clarify this.  Are you saying that the end user identity must be
present in the agent (as well as in the manager)?  Because if so, then the EUSM
approach would appear not to be viable because it dispenses with securityName in
the agent, only having Vacm group names (which is essentially what user1 to
usern are in my scribbles).

I agree with EUSM in wanting to dispense with end user identities in the agent
because that I see as the major hassle; but I part company from EUSM in wanting
a shared secret - not a protocol - betwen agent and security server.



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 28 11:50:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRBHC-0001s2-LG; Thu, 28 Apr 2005 11:50:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRBHB-0001qz-Ka
	for isms@megatron.ietf.org; Thu, 28 Apr 2005 11:50:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28201
	for <isms@ietf.org>; Thu, 28 Apr 2005 11:50:03 -0400 (EDT)
Received: from ranger.systems.pipex.net ([62.241.162.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRBU4-00005U-Ig
	for isms@ietf.org; Thu, 28 Apr 2005 12:03:25 -0400
Received: from pc6 (1Cust184.tnt103.lnd4.gbr.da.uu.net [213.116.54.184])
	by ranger.systems.pipex.net (Postfix) with SMTP id 4E45CE000148;
	Thu, 28 Apr 2005 16:49:39 +0100 (BST)
Message-ID: <050501c54c01$03b810c0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <ietfdbh@comcast.net>, <isms@ietf.org>
References: <20050426205203.E9C56E000091@national.systems.pipex.net>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Thu, 28 Apr 2005 16:01:51 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

<inline>
Tom Petch

----- Original Message -----
From: "David B Harrington" <ietfdbh@comcast.net>
Sent: Tuesday, April 26, 2005 10:51 PM

> Comment #1:
> One intention of the SNMPv3 approach was to enable logging of changes,
> including logging the securityName of the security principal. In your
> solution, there would be no security principal known at the agent, so
> audit logs could not be done. Is this correct?

Logging is possible.  securityName is not stored in the agent but is known (and
authenticated) to SNMP manager and security server, so the manager can put it in
the security parameters to enable logging; but it is the userj identifier that
is used for security checks at the agent on the incoming messages.

> Comment#2:
> Some applications already provide for user authentication via a
> centralized server, and then use the identity of the application as
> the SNMPv3 user. This allows for a very limited number of SNMPv3 users
> at the agent, while allowing user-specific authentication at the
> application. The application authorizes the authenticated user to
> utilize its user-independent application identity for SNMPv3.
>
> Your suggestion depends on a third-party server to provide a similar
> mapping between the authenticated-user at the application and a
> user-independent identity temporarily assigned by an
> authentication/authorization server used as the SNMPv3-user. Is that
> correct?
>
Yes (with the caveat above that the manager can include the end user name in the
message for eg logging).

It doesn't have to be a third party security server, it is just that everywhere
I go that is what I see ie noone logs onto a free standing Unix box using Unix
authentication prior to using Cisco Works, NetView, OpenView (and yes I know my
terminology is not what the vendors would like me to use:-).  Rather that that
Unix (or Microsoft or IBM ..) box is networked with others to a central security
server which keeps the authentication and authorisation for the end users.  So
it does not matter where I am in the organisation, the server I access finds out
that TP377 is allowed to user SNMP read access but not write, Telnet but not to
the firewalls, etc etc

Bundling the security server into the SNMP server as a single standalone box is
a subset of this and seemed a less flexible architecture.

<snip>


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Thu Apr 28 13:59:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRDI8-0004O3-N2; Thu, 28 Apr 2005 13:59:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRDI7-0004Ny-1v
	for isms@megatron.ietf.org; Thu, 28 Apr 2005 13:59:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08870
	for <isms@ietf.org>; Thu, 28 Apr 2005 13:59:09 -0400 (EDT)
Message-Id: <200504281759.NAA08870@ietf.org>
Received: from sccrmhc14.comcast.net ([204.127.202.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRDV0-0005bz-5z
	for isms@ietf.org; Thu, 28 Apr 2005 14:12:31 -0400
Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6])
	by comcast.net (sccrmhc14) with SMTP
	id <20050428175900014009qf6pe>; Thu, 28 Apr 2005 17:59:00 +0000
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Tom Petch'" <nwnetworks@dial.pipex.com>, <isms@ietf.org>
Subject: RE: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Thu, 28 Apr 2005 13:58:54 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <050501c54c01$03b810c0$0601a8c0@pc6>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVMCe1TJc6KaYwaQXmYqsaLqW7hbwABPhww
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi Tom, 

> > Comment #1:
> > One intention of the SNMPv3 approach was to enable logging 
> of changes,
> > including logging the securityName of the security 
> principal. In your
> > solution, there would be no security principal known at the 
> agent, so
> > audit logs could not be done. Is this correct?
> 
> Logging is possible.  securityName is not stored in the agent 
> but is known (and
> authenticated) to SNMP manager and security server, so the 
> manager can put it in
> the security parameters to enable logging; but it is the 
> userj identifier that
> is used for security checks at the agent on the incoming messages.

In this approach, is there any authentication of the securityName in
the security parameters, to ensure that the securityName and the
assigned userj identifier refer to the same security principal? If I
control the application, can I authenticate to get a userj identifier,
and then use a securityName of "Tom Petch" so your name gets logged
rather than mine when I do something I shouldn't? How does the SNMP
agent prevent such a misleading thing form occuring, or, if the agent
cannot detect and prevent this, how does an admin uncover this
deliberately misleading tactic?

> 
> > Comment#2:

> 
> Bundling the security server into the SNMP server as a single 
> standalone box is
> a subset of this and seemed a less flexible architecture.

When you say "SNMP server" are you referring to a manager (entity
acting as a command generator) or an agent (entity acting as a command
responder)?


David Harrington
dbharrington@comcast.net




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 05:41:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRS04-0005N2-QZ; Fri, 29 Apr 2005 05:41:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRS03-0005Mu-Ch
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 05:41:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08027
	for <isms@ietf.org>; Fri, 29 Apr 2005 05:41:26 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRSD3-0002GP-0s
	for isms@ietf.org; Fri, 29 Apr 2005 05:54:58 -0400
Received: from adsl-multi-1-c29-p057.vtx.ch ([212.147.29.57]
	helo=carter-zimmerman.mit.edu)
	by mx2.foretec.com with esmtp (Exim 4.24) id 1DRRzz-0000EK-Bg
	for isms@ietf.org; Fri, 29 Apr 2005 05:41:27 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id A6E6FE0063; Fri, 29 Apr 2005 05:36:07 -0400 (EDT)
To: isms@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 29 Apr 2005 05:36:07 -0400
Message-ID: <tsl1x8thqm0.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: 
Subject: [Isms] Meeting milestones
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org



Hi, folks.  We have two days in which to come to a decision on what
architecture to use.

I hope the discussion this Friday and Saturday is productive.  I think
our discussion over the last month has been very useful, but I am
concerned we are not at a consensus yet.


--Sam

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 09:18:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRVNn-0006JN-1S; Fri, 29 Apr 2005 09:18:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRVNk-0006JF-RQ
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 09:18:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23552
	for <isms@ietf.org>; Fri, 29 Apr 2005 09:18:11 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRVao-0003Qc-7R
	for isms@ietf.org; Fri, 29 Apr 2005 09:31:43 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 29 Apr 2005 06:18:03 -0700
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3TDHRhu023764;
	Fri, 29 Apr 2005 06:18:00 -0700 (PDT)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA16214;
	Fri, 29 Apr 2005 06:17:27 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200504291317.GAA16214@cisco.com>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
To: kaushik@cisco.com (Kaushik Narayan)
Date: Fri, 29 Apr 2005 06:17:27 -0700 (PDT)
In-Reply-To: <no.id> from "Kaushik Narayan" at Apr 26, 2005 05:54:11 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

  Out-of-band - Strongly favour
  In-band keying - Oppose
  Encapsulation keying - Oppose

Keith.

> I would like to ensure that ISMS members are making a choice on the
> architecture and not on the proposals, since the proposals themselves
> can work with a different architecture, for e.g. we can have EUSM work
> both with the current out-of-band keying model as well as an in-band
> keying model.
> 
> Here is my position
> 
> Out-of-band keying - Strongly favour. This approach introduces the
> minimal amount of change of SNMPv3 USM and achieves all the
> goals of ISMS.
> 
> In-band keying - Maybe,  again this position is for the architectural
> approach to negotiate keys using SNMP. I still strongly oppose the
> specifics of the SBSM proposal.
> 
> Encapsulation keying - Oppose.
> 
> 
> regards,
>    kaushik!
> 
> 
> At 02:21 PM 4/26/2005, Juergen Quittek wrote:
> >Dear all,
> >
> >We have to come to an agreement on the architecture we will use.
> >Ken asked some days ago, but only one of the replies stated a clear
> >position.
> >
> >Shall I take this as an indicator that the rest is not decided yet?
> >Or does not care?  Or can we go on with the table that Robert posted?
> >
> >>
> >>Keying|      For             | Against | Abstain
> >>------+----------------------+---------+-------------
> >>OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> >>IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> >>EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
> >>
> >>
> >>Key:  Y=YES/preference    (y=second pref/implied pref)
> >>       M=MAYBE/second pref (m=implied second pref)
> >>       N=NO
> >>       -=no explicit rejection (no comment)
> >>
> >>OOB | IB  | EK  | Name (alphabetical by first name)
> >>----+-----+-----+----------------------------------
> >>  N  |  N  |  Y  | David Harrington
> >>  -  |  y  |  -  | David Perkins
> >>  N  |  Y  |  M  | Ira McDonald
> >>  M  |  -  |  Y  | Juergen Schoenwaelder
> >>  Y  |  M  |  -  | Kaushik Narayan
> >>  Y  |  -  |  -  | Marcus Leech
> >>  Y  |  -  |  M  | Martin Soukup
> >>  N  |  Y  |  M  | Robert Story
> >>  m  |  y  |  Y  | Sam Hartman
> >>  Y  |  -  |  m  | Sharon Chisolm
> >>  -  |  M  |  Y  | Tom Petch
> >>  -  |  Y  |  Y  | Uri Blumenthal
> >>  -  |  Y  |  M  | Wes Hardaker
> >
> >Has anybody changed her/his mind?
> >Or does anybody want to replace a dash by a letter?
> >
> >Thanks,
> >
> >    Juergen
> >--
> >Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
> >NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> >Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
> >
> >
> >
> >--On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
> >
> >>ISMS members,
> >>
> >>There's been a lot of discussion recently on the mailing list about the
> >>pros and cons of different security models.  I think the discussion has
> >>been good, but unfortunately I don't think it's getting any closer to a
> >>consensus (I thank Robert for trying to draw things closer;
> >>unfortunately Juergen and I have been rather busy off-line, and I
> >>apologize for that).  I know that some on the mailing list have
> >>expressed a preference for choosing a security protocol first, but
> >>we've been tasked with choosing the architecture first, and I believe
> >>that is the appropriate approach.
> >>
> >>Anyway, I'd like to call for a consensus on the security architecture.
> >>As we all know, the three choices are:
> >>
> >>- Out of band keying (the architecture used by EUSM)
> >>- In-bakd keying (the architecture used by SBSM)
> >>- Encapsulation keying (the architecture used by TLSM)
> >>
> >>What I would like to see is WG members express which architecture(s)
> >>they prefer (you can choose more than one, but please, don't choose all
> >>three).  Please feel free to state your reasons for your choices, but
> >>in the interests of reaching consensus in a reasonable timeframe, I am
> >>asking that WG members please refrain from commenting on other people's
> >>choices unless they feel that the person has stated a fact which is
> >>obviously wrong.
> >>
> >>Thanks for your time,
> >>
> >>--Ken
> >>
> >>_______________________________________________
> >>Isms mailing list
> >>Isms@lists.ietf.org
> >>https://www1.ietf.org/mailman/listinfo/isms
> >
> >
> >
> >_______________________________________________
> >Isms mailing list
> >Isms@lists.ietf.org
> >https://www1.ietf.org/mailman/listinfo/isms
> 
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 09:24:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRVTf-0007AG-6P; Fri, 29 Apr 2005 09:24:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRVTe-0007AB-Gt
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 09:24:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23926
	for <isms@ietf.org>; Fri, 29 Apr 2005 09:24:16 -0400 (EDT)
Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRVgg-0003em-Ob
	for isms@ietf.org; Fri, 29 Apr 2005 09:37:49 -0400
Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59])
	by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,
	v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3TDO6Ed000777
	for <isms@ietf.org>; Fri, 29 Apr 2005 13:24:06 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com
	[132.233.42.126])
	by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,
	v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3TDNqBD030566
	for <isms@ietf.org>; Fri, 29 Apr 2005 13:24:06 GMT
Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148])
	by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id
	M2005042906240502849
	for <isms@ietf.org>; Fri, 29 Apr 2005 06:24:05 -0700
Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by
	fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 29 Apr 2005 06:24:06 -0700
Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by
	fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 29 Apr 2005 06:24:06 -0700
Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by
	hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 29 Apr 2005 09:24:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isms] Meeting milestones
Date: Fri, 29 Apr 2005 09:23:36 -0400
Message-ID: <3DEC199BD7489643817ECA151F7C5929010C8CFB@pysmsx401.amr.corp.intel.com>
Thread-Topic: [Isms] Meeting milestones
Thread-Index: AcVMn7xDyef+gW/gSGm+P2oM0eChWQAHU8JA
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <isms@ietf.org>
X-OriginalArrivalTime: 29 Apr 2005 13:24:05.0024 (UTC)
	FILETIME=[B7277200:01C54CBE]
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Well...

IMHO the best _architecture_ approach from the already-proposed ones is
SBSM. However _because_ of all the supported features wrt. Different
authentication mechanisms it needs a careful security review, which is
almost impossible to do.

Having said that - I'm strongly opposed to OOBK, support Encapsulated
and In-band. [The difference between In-band and Encapsulated tends to
get muddy]


-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]
On Behalf Of Sam Hartman
Sent: Friday, April 29, 2005 5:36 AM
To: isms@ietf.org
Subject: [Isms] Meeting milestones



Hi, folks.  We have two days in which to come to a decision on what
architecture to use.

I hope the discussion this Friday and Saturday is productive.  I think
our discussion over the last month has been very useful, but I am
concerned we are not at a consensus yet.


--Sam

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 10:51:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRWpm-00041P-CG; Fri, 29 Apr 2005 10:51:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRWpk-00041K-ID
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 10:51:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02625
	for <isms@ietf.org>; Fri, 29 Apr 2005 10:51:08 -0400 (EDT)
Received: from adsl-multi-1-c29-p057.vtx.ch ([212.147.29.57]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRX2m-0007aJ-Oy
	for isms@ietf.org; Fri, 29 Apr 2005 11:04:42 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 2649EE0063; Fri, 29 Apr 2005 10:50:50 -0400 (EDT)
To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: Re: [Isms] Meeting milestones
References: <3DEC199BD7489643817ECA151F7C5929010C8CFB@pysmsx401.amr.corp.intel.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 29 Apr 2005 10:50:50 -0400
In-Reply-To: <3DEC199BD7489643817ECA151F7C5929010C8CFB@pysmsx401.amr.corp.intel.com>
	(Uri Blumenthal's message of "Fri, 29 Apr 2005 09:23:36 -0400")
Message-ID: <tslr7gteiwl.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> "Blumenthal," == Blumenthal, Uri <uri.blumenthal@intel.com> writes:

    Blumenthal,> Well...  IMHO the best _architecture_ approach from
    Blumenthal,> the already-proposed ones is SBSM. However _because_
    Blumenthal,> of all the supported features wrt. Different
    Blumenthal,> authentication mechanisms it needs a careful security
    Blumenthal,> review, which is almost impossible to do.

SBSM is a protocol, not an architecture.  The architecture is IBK.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 12:51:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRYiK-0001l1-Ve; Fri, 29 Apr 2005 12:51:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRYiI-0001kw-W9
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 12:51:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14244
	for <isms@ietf.org>; Fri, 29 Apr 2005 12:51:36 -0400 (EDT)
Received: from adsl-64-165-72-150.dsl.scrm01.pacbell.net ([64.165.72.150]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRYvO-0004r6-DF
	for isms@ietf.org; Fri, 29 Apr 2005 13:05:11 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 0D8F711D944; Fri, 29 Apr 2005 09:51:33 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Tom Petch <nwnetworks@dial.pipex.com>
Subject: Re: [Isms] securityName in Keep the agent simple;
	was RADIUS is not a trusted third party
Organization: Sparta
References: <200504262037.j3QKbsTL016489@ginger.cmf.nrl.navy.mil>
	<050201c54c00$f9ee9280$0601a8c0@pc6>
Date: Fri, 29 Apr 2005 09:51:32 -0700
In-Reply-To: <050201c54c00$f9ee9280$0601a8c0@pc6> (Tom Petch's message of
	"Thu, 28 Apr 2005 15:44:41 +0200")
Message-ID: <sdwtqlv84r.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Thu, 28 Apr 2005 15:44:41 +0200, "Tom Petch" <nwnetworks@dial.pipex.com> said:

Tom> I would like to clarify this.  Are you saying that the end user
Tom> identity must be present in the agent (as well as in the
Tom> manager)?

He's saying that an authentication mechanism already exists in the
device.  That mechanism may be a an end user identity and method of
confirmation or it may be that the device is already configured to
talk to a RADIUS server.  The important part is that they don't want
*add* something new.  Operators that don't use RADIUS or other
centralized AAA architecture won't want to add it just to deploy
SNMP.  Similarly, operators that have done away with on-the-device
accounts in favor of centralized services won't want to deploy
on-the-device accounts.

That's what makes the problem hard.  It's actually multiple problems
that should have the same end requirements in the operators eyes: use
what they have, not something else.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 15:11:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRatr-0002J8-Qk; Fri, 29 Apr 2005 15:11:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRatp-0002J3-Kf
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 15:11:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29861
	for <isms@ietf.org>; Fri, 29 Apr 2005 15:11:39 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRb6w-0004p3-09
	for isms@ietf.org; Fri, 29 Apr 2005 15:25:15 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-2.cisco.com with ESMTP; 29 Apr 2005 12:11:32 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3TJB33A002707;
	Fri, 29 Apr 2005 12:11:26 -0700 (PDT)
Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 29 Apr 2005 12:11:24 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Isms] securityName in Keep the agent simple;
	was RADIUS is not a trusted third party
Date: Fri, 29 Apr 2005 12:11:18 -0700
Message-ID: <BC5CFB047387BD41AC606027302F1FDD13FD3C@xmb-sjc-22e.amer.cisco.com>
Thread-Topic: [Isms] securityName in Keep the agent simple;
	was RADIUS is not a trusted third party
Thread-Index: AcVM3G+2pOQA5xCJShmaQxpZFcCwZwAEhwUA
From: "Khanh Nguyen \(khanhvn\)" <khanhvn@cisco.com>
To: "Wes Hardaker" <hardaker@tislabs.com>,
	"Tom Petch" <nwnetworks@dial.pipex.com>
X-OriginalArrivalTime: 29 Apr 2005 19:11:24.0712 (UTC)
	FILETIME=[3C937A80:01C54CEF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

> From:  Wes Hardaker
>
> ... Operators that don't use RADIUS or=20
> other centralized AAA architecture won't want to add it just=20
> to deploy SNMP.  Similarly, operators that have done away=20
> with on-the-device accounts in favor of centralized services=20
> won't want to deploy on-the-device accounts.
>=20
> That's what makes the problem hard.  It's actually multiple=20
> problems that should have the same end requirements in the=20
> operators eyes: use what they have, not something else.
>=20

So I think the ideal solution should be able to give operators
both choices: local user account and/or centralized AAA users.
I think EUSM, for example, supports both modes.

Khanh

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 15:18:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRb0Q-0003EL-IU; Fri, 29 Apr 2005 15:18:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRb0N-0003EG-TS
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 15:18:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00772
	for <isms@ietf.org>; Fri, 29 Apr 2005 15:18:26 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRbDT-0005GN-M1
	for isms@ietf.org; Fri, 29 Apr 2005 15:32:01 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3TJIJCN019433
	for <isms@ietf.org>; Fri, 29 Apr 2005 15:18:19 -0400 (EDT)
Message-Id: <200504291918.j3TJIJCN019433@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
Subject: Re: [Isms] securityName in Keep the agent simple;
	was RADIUS is not a trusted third party 
In-Reply-To: <BC5CFB047387BD41AC606027302F1FDD13FD3C@xmb-sjc-22e.amer.cisco.com>
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Fri, 29 Apr 2005 15:18:20 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>So I think the ideal solution should be able to give operators
>both choices: local user account and/or centralized AAA users.
>I think EUSM, for example, supports both modes.

I agree that EUSM supports both of those modes; I'm not sure it supports
everything that people wanted, but that's not really important now.

But in terms of _architecture_ (which is what we're talking about), I
think any of the three architectures _could be made_ to support all of
the security systems that operators have expressed interest in.

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 15:20:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRb2F-0003cL-Dg; Fri, 29 Apr 2005 15:20:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRb2D-0003c7-Tk
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 15:20:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01057
	for <isms@ietf.org>; Fri, 29 Apr 2005 15:20:20 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRbFK-0005In-FY
	for isms@ietf.org; Fri, 29 Apr 2005 15:33:55 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 2301D11D944; Fri, 29 Apr 2005 12:20:18 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "Khanh Nguyen (khanhvn)" <khanhvn@cisco.com>
Subject: Re: [Isms] securityName in Keep the agent simple;
	was RADIUS is not a trusted third party
Organization: Sparta
References: <BC5CFB047387BD41AC606027302F1FDD13FD3C@xmb-sjc-22e.amer.cisco.com>
Date: Fri, 29 Apr 2005 12:20:17 -0700
In-Reply-To: <BC5CFB047387BD41AC606027302F1FDD13FD3C@xmb-sjc-22e.amer.cisco.com>
	(Khanh Nguyen's message of "Fri, 29 Apr 2005 12:11:18 -0700")
Message-ID: <sdhdhp2xvy.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Fri, 29 Apr 2005 12:11:18 -0700, "Khanh Nguyen (khanhvn)" <khanhvn@cisco.com> said:

Khanh> So I think the ideal solution should be able to give operators
Khanh> both choices: local user account and/or centralized AAA users.
Khanh> I think EUSM, for example, supports both modes.

Every solution presented to date does (though it's spelled out better
in some than others).

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 16:08:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRbnG-0007RE-8q; Fri, 29 Apr 2005 16:08:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRbnE-0007Qu-Se
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 16:08:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07770
	for <isms@ietf.org>; Fri, 29 Apr 2005 16:08:54 -0400 (EDT)
Received: from blaster.systems.pipex.net ([62.241.163.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRc0J-0008Vo-Qx
	for isms@ietf.org; Fri, 29 Apr 2005 16:22:30 -0400
Received: from pc6 (1Cust237.tnt104.lnd4.gbr.da.uu.net [213.116.56.237])
	by blaster.systems.pipex.net (Postfix) with SMTP id 3CDA6E00009D;
	Fri, 29 Apr 2005 21:08:32 +0100 (BST)
Message-ID: <001401c54cee$4fddf1c0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <ietfdbh@comcast.net>, <isms@ietf.org>
References: <20050428175901.C711EE00008F@hood.systems.pipex.net>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Fri, 29 Apr 2005 21:02:47 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

<inline>
Tom Petch
----- Original Message -----
From: "David B Harrington" <ietfdbh@comcast.net>
To: "'Tom Petch'" <nwnetworks@dial.pipex.com>; <isms@ietf.org>
Sent: Thursday, April 28, 2005 7:58 PM
Subject: RE: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party


> > > Comment #1:
> > > One intention of the SNMPv3 approach was to enable logging
> > of changes,
> > > including logging the securityName of the security
> > principal. In your
> > > solution, there would be no security principal known at the
> > agent, so
> > > audit logs could not be done. Is this correct?
> >
> > Logging is possible.  securityName is not stored in the agent
> > but is known (and
> > authenticated) to SNMP manager and security server, so the
> > manager can put it in
> > the security parameters to enable logging; but it is the
> > userj identifier that
> > is used for security checks at the agent on the incoming messages.
>
> In this approach, is there any authentication of the securityName in
> the security parameters, to ensure that the securityName and the
> assigned userj identifier refer to the same security principal? If I
> control the application, can I authenticate to get a userj identifier,
> and then use a securityName of "Tom Petch" so your name gets logged
> rather than mine when I do something I shouldn't? How does the SNMP
> agent prevent such a misleading thing form occuring, or, if the agent
> cannot detect and prevent this, how does an admin uncover this
> deliberately misleading tactic?

Ultimately, you probably cannot in a cryptographically strong manner.  If the
SNMP manager-server is open to attack, then there is little security since it
will have a local store of agent, session keys, end-user etc  I assume the
manager runs on such as Microsoft Windows Server 2003 or IBM z/OS or a Unix
equivalent which can protect their information when needed.  So the manager only
has permission from the security server to set up a session and send PDU from a
specified user-name to a specified agent and that is all that will happen.  The
protection depends on the shared secret between SNMP manager-server and security
server and the way in which the servers are built.

Third party security- Kerberos - is stronger but that requires more work at the
agent which it is my starting point not to have.

I don't expect most agents to log much - they are mostly entry level devices -
with servers (security, SNMP manager etc) doing most of that.  I expect logging
at the security server - ie AAA - it knows the end-user credentials, what
userj was used by them at which agent, potentially from which workstation; and
at the SNMP manager-server, which has much of the same information.

> >
> > > Comment#2:
>
> > Bundling the security server into the SNMP server as a single
> > standalone box is
> > a subset of this and seemed a less flexible architecture.
>
> When you say "SNMP server" are you referring to a manager (entity
> acting as a command generator) or an agent (entity acting as a command
> responder)?
>
>
> David Harrington
> dbharrington@comcast.net
>
SNMP manager-server:-) ie a server-type platform - Windows Server 2003, z\OS,
Unix - with an SNMP command generator (yes, I know, and sometimes forget, that
the command responder is
really the server of a client-server relationship, port 161 and all that).  The
split in roles in SNMPv3 is a nice flexibility to have but is not something I
see much of yet, so I cast the security issue in terms of traditional SNMP
manager-agent.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 16:26:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRc48-0003VT-S0; Fri, 29 Apr 2005 16:26:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRc47-0003Uc-Qy
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 16:26:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11848
	for <isms@ietf.org>; Fri, 29 Apr 2005 16:26:21 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRcHF-00025i-67
	for isms@ietf.org; Fri, 29 Apr 2005 16:39:58 -0400
Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	(authenticated bits=0)
	by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id
	j3TKQGq2020968
	for <isms@ietf.org>; Fri, 29 Apr 2005 16:26:16 -0400 (EDT)
Message-Id: <200504292026.j3TKQGq2020968@ginger.cmf.nrl.navy.mil>
To: isms@ietf.org
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
In-Reply-To: <001401c54cee$4fddf1c0$0601a8c0@pc6> 
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
	WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
	gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK; C*}fMI;
	Mv(aiO2z~9n.w?@\>kEpSD@*e`
Date: Fri, 29 Apr 2005 16:26:17 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
X-Spam-Score: () hits=0 User Authenticated
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>Third party security- Kerberos - is stronger but that requires more work at the
>agent which it is my starting point not to have.

<WG chair hat off>

I feel I must correct you here.  Kerberos requires relatively little
work at the _agent_.  In fact, Kerberos servers are relatively simple,
from both a management and programming aspect (we can debate what is
"simple" and what is not, but I'm just talking about the relation
between the manager and the agent).  The _manager_ is more complex.
This is of course not true for all trusted third party systems.

Sometimes I think the amount of complexity required for authentication
is constant, and the only real difference between different systems is
where they choose to put the complexity.  I know that's not true, but
it sure seems like it at times :-)

--Ken

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 16:44:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRcM7-0008B3-Gq; Fri, 29 Apr 2005 16:44:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRcM4-0008At-Ot
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 16:44:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13219
	for <isms@ietf.org>; Fri, 29 Apr 2005 16:44:54 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRcZD-0003AR-7x
	for isms@ietf.org; Fri, 29 Apr 2005 16:58:31 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id A1DD611D944; Fri, 29 Apr 2005 13:44:53 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Tom Petch <nwnetworks@dial.pipex.com>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Organization: Sparta
References: <20050428175901.C711EE00008F@hood.systems.pipex.net>
	<001401c54cee$4fddf1c0$0601a8c0@pc6>
Date: Fri, 29 Apr 2005 13:44:52 -0700
In-Reply-To: <001401c54cee$4fddf1c0$0601a8c0@pc6> (Tom Petch's message of
	"Fri, 29 Apr 2005 21:02:47 +0200")
Message-ID: <sdvf651fej.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Fri, 29 Apr 2005 21:02:47 +0200, "Tom Petch" <nwnetworks@dial.pipex.com> said:

Tom> I don't expect most agents to log much - they are mostly entry
Tom> level devices - with servers (security, SNMP manager etc) doing
Tom> most of that.  I expect logging at the security server - ie AAA -
Tom> it knows the end-user credentials, what userj was used by them at
Tom> which agent, potentially from which workstation; and at the SNMP
Tom> manager-server, which has much of the same information.

Yes, but the only auditing that can be done doesn't include the actual
operations unless you're doing the auditing on the device itself.  I
could tell you my password, and I'd know I gave it to you and what you
could potentially do with it when logging into the machines I have
accounts on.  Only the machine could actually log what you did while
on the system though.

Putting all your trust into the management station and not putting
decent security services into the device itself is a recipe for
trouble.  Having said that, if you want to deploy your network such
that each user gets mapped to the same over-the-network root principal
to perform actions then that is your choice, but you certainly better
understand the security principals involved in how that management
software was developed.  It's *much* easier to attack a running
application to steal network keys from it than it is to attack a
remote machine when you don't know the network keys for it.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 18:14:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRdim-0007Bb-G5; Fri, 29 Apr 2005 18:12:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRdik-0007BW-Gm
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 18:12:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21681
	for <isms@ietf.org>; Fri, 29 Apr 2005 18:12:23 -0400 (EDT)
Received: from moby.atcorp.com ([204.72.172.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRdvt-00080s-Dk
	for isms@ietf.org; Fri, 29 Apr 2005 18:26:01 -0400
Received: from localhost ([127.0.0.1] helo=STRIPER ident=root)
	by moby.atcorp.com with asmtp (Exim 3.35 #1 (Debian))
	id 1DRdia-00022d-00; Fri, 29 Apr 2005 17:12:16 -0500
From: "Wayne Kading" <wkading@atcorp.com>
To: <isms@ietf.org>
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Fri, 29 Apr 2005 17:12:15 -0500
Organization: ATC
Message-ID: <004501c54d08$807e86e0$84aca8c0@STRIPER>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <75F1B11B7830A96E6F82DA9E@[192.168.0.128]>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

My position on the ISMS keying architecture follows.

OOBK - m-maybe
IBK  - M-Maybe
EK   - Y-Yes

I like the decoupling of the authentication function from the privacy and
data integrity functions offered by EK.  I have security concerns with IBK
and complexity concerns with OOBK which were expressed in other posts by
this WG.

Wayne Kading
Architecture Technology, Corp.
Minneapolis, MN

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
Behalf Of Juergen Quittek
Sent: Tuesday, April 26, 2005 4:22 PM
To: isms@ietf.org
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture

Dear all,

We have to come to an agreement on the architecture we will use.
Ken asked some days ago, but only one of the replies stated a clear
position.

Shall I take this as an indicator that the rest is not decided yet?
Or does not care?  Or can we go on with the table that Robert posted?

>
> Keying|      For             | Against | Abstain
> ------+----------------------+---------+-------------
> OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
>
>
> Key:  Y=YES/preference    (y=second pref/implied pref)
>       M=MAYBE/second pref (m=implied second pref)
>       N=NO
>       -=no explicit rejection (no comment)
>
> OOB | IB  | EK  | Name (alphabetical by first name)
> ----+-----+-----+----------------------------------
>  N  |  N  |  Y  | David Harrington
>  -  |  y  |  -  | David Perkins
>  N  |  Y  |  M  | Ira McDonald
>  M  |  -  |  Y  | Juergen Schoenwaelder
>  Y  |  M  |  -  | Kaushik Narayan
>  Y  |  -  |  -  | Marcus Leech
>  Y  |  -  |  M  | Martin Soukup
>  N  |  Y  |  M  | Robert Story
>  m  |  y  |  Y  | Sam Hartman
>  Y  |  -  |  m  | Sharon Chisolm
>  -  |  M  |  Y  | Tom Petch
>  -  |  Y  |  Y  | Uri Blumenthal
>  -  |  Y  |  M  | Wes Hardaker
>

Has anybody changed her/his mind?
Or does anybody want to replace a dash by a letter?

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de



--On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:

> ISMS members,
>
> There's been a lot of discussion recently on the mailing list about the
> pros and cons of different security models.  I think the discussion has
> been good, but unfortunately I don't think it's getting any closer to a
> consensus (I thank Robert for trying to draw things closer;
> unfortunately Juergen and I have been rather busy off-line, and I
> apologize for that).  I know that some on the mailing list have
> expressed a preference for choosing a security protocol first, but
> we've been tasked with choosing the architecture first, and I believe
> that is the appropriate approach.
>
> Anyway, I'd like to call for a consensus on the security architecture.
> As we all know, the three choices are:
>
> - Out of band keying (the architecture used by EUSM)
> - In-bakd keying (the architecture used by SBSM)
> - Encapsulation keying (the architecture used by TLSM)
>
> What I would like to see is WG members express which architecture(s)
> they prefer (you can choose more than one, but please, don't choose all
> three).  Please feel free to state your reasons for your choices, but
> in the interests of reaching consensus in a reasonable timeframe, I am
> asking that WG members please refrain from commenting on other people's
> choices unless they feel that the person has stated a fact which is
> obviously wrong.
>
> Thanks for your time,
>
> --Ken
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 18:14:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRdiY-00079p-4k; Fri, 29 Apr 2005 18:12:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRdiW-000788-GH
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 18:12:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21637
	for <isms@ietf.org>; Fri, 29 Apr 2005 18:12:09 -0400 (EDT)
Received: from blaster.systems.pipex.net ([62.241.163.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRdvf-000809-2p
	for isms@ietf.org; Fri, 29 Apr 2005 18:25:47 -0400
Received: from pc6 (1Cust237.tnt104.lnd4.gbr.da.uu.net [213.116.56.237])
	by blaster.systems.pipex.net (Postfix) with SMTP id 5041BE000041;
	Fri, 29 Apr 2005 23:11:49 +0100 (BST)
Message-ID: <006801c54cff$8c724e40$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Wes Hardaker" <hardaker@tislabs.com>
References: <20050428175901.C711EE00008F@hood.systems.pipex.net><001401c54cee$4fddf1c0$0601a8c0@pc6>
	<sdvf651fej.fsf@wes.hardakers.net>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Date: Fri, 29 Apr 2005 23:06:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

I agree that a shared secret (with a security server) in the agent with limited
logging is not as secure as USM.  Armour-plated security requires more work,
more hassle at the large number of remote agents and USM gives both:-)  And your
survey of operators showed a number who are happy with USM so for them, the
tradeoff is ok.

But USM does not scale, it does not scale down to the smaller organisations, the
like of which I see using telnet to login to a remote router to make
configuration changes with userid and password sent in the clear over the
network - and they think they have got security.  A shared secret that is never
sent anywhere, a fresh key for each session, that is a big increase in security
for them even if it is not up to USM standards.  It is scalability, better
security with one touch at the agent, that drives me.  And, as I said, this
shared secret with a security server can be updated as often and as much as the
organisation wants to get harder security - just don't put end user ids, their
keys, certificates etc into the agent as well:-)

Does that make me OOBK?  I am still thinking about it.

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <hardaker@tislabs.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>
Cc: <ietfdbh@comcast.net>; <isms@ietf.org>
Sent: Friday, April 29, 2005 10:44 PM
Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third
party


> >>>>> On Fri, 29 Apr 2005 21:02:47 +0200, "Tom Petch"
<nwnetworks@dial.pipex.com> said:
>
> Tom> I don't expect most agents to log much - they are mostly entry
> Tom> level devices - with servers (security, SNMP manager etc) doing
> Tom> most of that.  I expect logging at the security server - ie AAA -
> Tom> it knows the end-user credentials, what userj was used by them at
> Tom> which agent, potentially from which workstation; and at the SNMP
> Tom> manager-server, which has much of the same information.
>
> Yes, but the only auditing that can be done doesn't include the actual
> operations unless you're doing the auditing on the device itself.  I
> could tell you my password, and I'd know I gave it to you and what you
> could potentially do with it when logging into the machines I have
> accounts on.  Only the machine could actually log what you did while
> on the system though.
>
> Putting all your trust into the management station and not putting
> decent security services into the device itself is a recipe for
> trouble.  Having said that, if you want to deploy your network such
> that each user gets mapped to the same over-the-network root principal
> to perform actions then that is your choice, but you certainly better
> understand the security principals involved in how that management
> software was developed.  It's *much* easier to attack a running
> application to steal network keys from it than it is to attack a
> remote machine when you don't know the network keys for it.
>
> --
> Wes Hardaker
> Sparta, Inc.


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 18:22:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRdsR-0004rj-7H; Fri, 29 Apr 2005 18:22:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRdsH-0004nV-PH
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 18:22:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23889
	for <isms@ietf.org>; Fri, 29 Apr 2005 18:22:14 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRe5O-0000ED-Ob
	for isms@ietf.org; Fri, 29 Apr 2005 18:35:52 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 01FFA11D944; Fri, 29 Apr 2005 15:22:11 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: Keith McCloghrie <kzm@cisco.com>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Organization: Sparta
References: <200504291317.GAA16214@cisco.com>
Date: Fri, 29 Apr 2005 15:22:10 -0700
In-Reply-To: <200504291317.GAA16214@cisco.com> (Keith McCloghrie's message of
	"Fri, 29 Apr 2005 06:17:27 -0700 (PDT)")
Message-ID: <sdll711awd.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Fri, 29 Apr 2005 06:17:27 -0700 (PDT), Keith McCloghrie <kzm@cisco.com> said:

Keith> Out-of-band - Strongly favour
Keith> In-band keying - Oppose
Keith> Encapsulation keying - Oppose

I'd like to remind the people that have indicated that only one
solution is acceptable that this sort of attitude will likely sink the
WG entirely.  Consensus, as David Perkins reminded me on the phone a
few minutes ago, is the willingness of people to come together to
agree on something that will be satisfactory for most people even if
not ideal.  I encourage people to consider carefully the consequences
of stating that you're unwilling to adopt any approach but your
favorite.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 18:24:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRduQ-0005KE-Ge; Fri, 29 Apr 2005 18:24:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRduO-0005K6-R1
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 18:24:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25566
	for <isms@ietf.org>; Fri, 29 Apr 2005 18:24:25 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRe7Y-0000Sf-34
	for isms@ietf.org; Fri, 29 Apr 2005 18:38:04 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 7D09B11D944; Fri, 29 Apr 2005 15:24:25 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Organization: Sparta
References: <20050428175901.C711EE00008F@hood.systems.pipex.net>
	<001401c54cee$4fddf1c0$0601a8c0@pc6>
	<sdvf651fej.fsf@wes.hardakers.net>
	<006801c54cff$8c724e40$0601a8c0@pc6>
Date: Fri, 29 Apr 2005 15:24:24 -0700
In-Reply-To: <006801c54cff$8c724e40$0601a8c0@pc6> (Tom Petch's message of
	"Fri, 29 Apr 2005 23:06:27 +0200")
Message-ID: <sd8y311asn.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Fri, 29 Apr 2005 23:06:27 +0200, "Tom Petch" <nwnetworks@dial.pipex.com> said:

Tom> But USM does not scale

Never said otherwise.

Your argument was that all trust should occur at the management
station, though, and it should be configured with keys to the kingdom
and parse out information from there as to who can do what.  That
doesn't fly in my book is all I was saying.  (this is different than
Kerberos, which is a centralized service running on one host that most
NM users wouldn't have access too.)

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 20:53:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRgER-0004Pu-R4; Fri, 29 Apr 2005 20:53:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRgER-0004Pp-5d
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 20:53:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06080
	for <isms@ietf.org>; Fri, 29 Apr 2005 20:53:17 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRgRb-0007Vv-O0
	for isms@ietf.org; Fri, 29 Apr 2005 21:06:56 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 29 Apr 2005 17:53:10 -0700
X-IronPort-AV: i="3.92,141,1112598000"; 
	d="scan'208"; a="256541976:sNHT30677268"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com
	[10.93.132.68])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3U0r5Kx012303;
	Fri, 29 Apr 2005 17:53:05 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Fri, 29 Apr 2005 17:56:46 -0700
Message-ID: <7210B31550AC934A8637D6619739CE69051409F3@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Thread-Index: AcVKpvsuf+isrH+EQVy8VL/C3xGh9gCd3+Mg
From: "Salowey, Joe" <jsalowey@cisco.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>, <isms@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org


The motivation for EUSM was to implement a solution with minimal changes
to USM.  For this reason we choose to use out-of-band keying.  I am
still strongly in favor of out-of-band keying.

I have not been convinced by any of the discussion that out-of-band
keying is any more difficult or problematic than any of the other
methods so I am opposed to both encapsulation and in-band keying as I
believe they both will require more changes to existing USM
implementations.  =20

If it is shown that another keying architecture is less invasive to USM
or the working group decides that protection mechanisms within USM need
to be replaced then I would reconsider my opposition.=20

Joe=20

> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@netlab.nec.de]=20
> Sent: Tuesday, April 26, 2005 2:22 PM
> To: isms@ietf.org
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
>=20
> Dear all,
>=20
> We have to come to an agreement on the architecture we will use.
> Ken asked some days ago, but only one of the replies stated a=20
> clear position.
>=20
> Shall I take this as an indicator that the rest is not decided yet?
> Or does not care?  Or can we go on with the table that Robert posted?
>=20
> >
> > Keying|      For             | Against | Abstain
> > ------+----------------------+---------+-------------
> > OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> > IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> > EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
> >
> >
> > Key:  Y=3DYES/preference    (y=3Dsecond pref/implied pref)
> >       M=3DMAYBE/second pref (m=3Dimplied second pref)
> >       N=3DNO
> >       -=3Dno explicit rejection (no comment)
> >
> > OOB | IB  | EK  | Name (alphabetical by first name)
> > ----+-----+-----+----------------------------------
> >  N  |  N  |  Y  | David Harrington
> >  -  |  y  |  -  | David Perkins
> >  N  |  Y  |  M  | Ira McDonald
> >  M  |  -  |  Y  | Juergen Schoenwaelder  Y  |  M  |  -  | Kaushik=20
> > Narayan  Y  |  -  |  -  | Marcus Leech  Y  |  -  |  M  |=20
> Martin Soukup =20
> > N  |  Y  |  M  | Robert Story  m  |  y  |  Y  | Sam Hartman=20
>  Y  |  - =20
> > |  m  | Sharon Chisolm
> >  -  |  M  |  Y  | Tom Petch
> >  -  |  Y  |  Y  | Uri Blumenthal
> >  -  |  Y  |  M  | Wes Hardaker
> >
>=20
> Has anybody changed her/his mind?
> Or does anybody want to replace a dash by a letter?
>=20
> Thanks,
>=20
>     Juergen
> --=20
> Juergen Quittek        quittek@netlab.nec.de       Tel: +49=20
> 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49=20
> 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany  =20
> http://www.netlab.nec.de
>=20
>=20
>=20
> --On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
>=20
> > ISMS members,
> >
> > There's been a lot of discussion recently on the mailing list about=20
> > the pros and cons of different security models.  I think the=20
> > discussion has been good, but unfortunately I don't think=20
> it's getting=20
> > any closer to a consensus (I thank Robert for trying to draw things=20
> > closer; unfortunately Juergen and I have been rather busy off-line,=20
> > and I apologize for that).  I know that some on the mailing=20
> list have=20
> > expressed a preference for choosing a security protocol first, but=20
> > we've been tasked with choosing the architecture first, and=20
> I believe=20
> > that is the appropriate approach.
> >
> > Anyway, I'd like to call for a consensus on the security=20
> architecture.
> > As we all know, the three choices are:
> >
> > - Out of band keying (the architecture used by EUSM)
> > - In-bakd keying (the architecture used by SBSM)
> > - Encapsulation keying (the architecture used by TLSM)
> >
> > What I would like to see is WG members express which=20
> architecture(s)=20
> > they prefer (you can choose more than one, but please, don't choose=20
> > all three).  Please feel free to state your reasons for=20
> your choices,=20
> > but in the interests of reaching consensus in a reasonable=20
> timeframe,=20
> > I am asking that WG members please refrain from commenting on other=20
> > people's choices unless they feel that the person has stated a fact=20
> > which is obviously wrong.
> >
> > Thanks for your time,
> >
> > --Ken
> >
> > _______________________________________________
> > Isms mailing list
> > Isms@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/isms
>=20
>=20
>=20
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
>=20

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 22:08:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRhP6-00066P-VO; Fri, 29 Apr 2005 22:08:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRhP5-00066B-78
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 22:08:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10028
	for <isms@ietf.org>; Fri, 29 Apr 2005 22:08:21 -0400 (EDT)
Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRhcF-0002Sg-Df
	for isms@ietf.org; Fri, 29 Apr 2005 22:22:00 -0400
Received: from h-68-164-242-11.snvacaid.dynamic.covad.net ([68.164.242.11]
	helo=oemcomputer)
	by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DRhOx-0002yd-00
	for isms@ietf.org; Fri, 29 Apr 2005 19:08:15 -0700
Message-ID: <003901c54d29$c13fa9e0$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <200504292026.j3TKQGq2020968@ginger.cmf.nrl.navy.mil>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party 
Date: Fri, 29 Apr 2005 19:10:17 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi -

> From: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
> To: <isms@ietf.org>
> Sent: Friday, April 29, 2005 1:26 PM
> Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third party
>

> >Third party security- Kerberos - is stronger but that requires more work at the
> >agent which it is my starting point not to have.
>
> <WG chair hat off>
>
> I feel I must correct you here.  Kerberos requires relatively little
> work at the _agent_.  In fact, Kerberos servers are relatively simple,
> from both a management and programming aspect (we can debate what is
> "simple" and what is not, but I'm just talking about the relation
> between the manager and the agent).  The _manager_ is more complex.
> This is of course not true for all trusted third party systems.

I don't see how things would be any simpler at an "agent"
if it supports sending notifications as Informs.

> Sometimes I think the amount of complexity required for authentication
> is constant, and the only real difference between different systems is
> where they choose to put the complexity.  I know that's not true, but
> it sure seems like it at times :-)
...

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 22:51:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRi54-0007h8-8x; Fri, 29 Apr 2005 22:51:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRi52-0007h3-NC
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 22:51:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12146
	for <isms@ietf.org>; Fri, 29 Apr 2005 22:51:42 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRiIC-0004SD-En
	for isms@ietf.org; Fri, 29 Apr 2005 23:05:22 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 4FE5E11D944; Fri, 29 Apr 2005 19:51:37 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Organization: Sparta
References: <200504292026.j3TKQGq2020968@ginger.cmf.nrl.navy.mil>
	<003901c54d29$c13fa9e0$7f1afea9@oemcomputer>
Date: Fri, 29 Apr 2005 19:51:33 -0700
In-Reply-To: <003901c54d29$c13fa9e0$7f1afea9@oemcomputer> (Randy Presuhn's
	message of "Fri, 29 Apr 2005 19:10:17 -0700")
Message-ID: <sdbr7xou2y.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Fri, 29 Apr 2005 19:10:17 -0700, "Randy Presuhn" <randy_presuhn@mindspring.com> said:

>> I feel I must correct you here.  Kerberos requires relatively little
>> work at the _agent_.  In fact, Kerberos servers are relatively simple,
>> from both a management and programming aspect (we can debate what is
>> "simple" and what is not, but I'm just talking about the relation
>> between the manager and the agent).  The _manager_ is more complex.
>> This is of course not true for all trusted third party systems.

Randy> I don't see how things would be any simpler at an "agent"
Randy> if it supports sending notifications as Informs.

If you're making the assumption that USM will be used to protect the
packets, then you're right.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Fri Apr 29 22:58:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRiBN-0000eD-Bp; Fri, 29 Apr 2005 22:58:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRiBL-0000e8-JG
	for isms@megatron.ietf.org; Fri, 29 Apr 2005 22:58:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12456
	for <isms@ietf.org>; Fri, 29 Apr 2005 22:58:13 -0400 (EDT)
Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43]
	helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DRiOX-0004jP-AF
	for isms@ietf.org; Fri, 29 Apr 2005 23:11:53 -0400
Received: by wes.hardakers.net (Postfix, from userid 274)
	id 3F16F11D944; Fri, 29 Apr 2005 19:58:12 -0700 (PDT)
From: Wes Hardaker <hardaker@tislabs.com>
To: "Salowey, Joe" <jsalowey@cisco.com>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Organization: Sparta
References: <7210B31550AC934A8637D6619739CE69051409F3@e2k-sea-xch2.sea-alpha.cisco.com>
Date: Fri, 29 Apr 2005 19:58:11 -0700
In-Reply-To: <7210B31550AC934A8637D6619739CE69051409F3@e2k-sea-xch2.sea-alpha.cisco.com>
	(Joe Salowey's message of "Fri, 29 Apr 2005 17:56:46 -0700")
Message-ID: <sdis25nf7g.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

>>>>> On Fri, 29 Apr 2005 17:56:46 -0700, "Salowey, Joe" <jsalowey@cisco.com> said:

Joe> The motivation for EUSM was to implement a solution with minimal
Joe> changes to USM.

For reasons I've still yet to see posted to the list, although I've asked.

Joe> For this reason we choose to use out-of-band keying.  I am still
Joe> strongly in favor of out-of-band keying.

Every architecture could use USM underneath for traffic protection, so
that's not really a good argument for OOB, IMHO.

Joe> I have not been convinced by any of the discussion that
Joe> out-of-band keying is any more difficult or problematic than any
Joe> of the other methods so I am opposed to both encapsulation and
Joe> in-band keying as I believe they both will require more changes
Joe> to existing USM implementations.

If you want to use USM and if you assume it will be used then it
probably won't matter which architecture you pick because the results
of implementing any of the architectures could be feeding the keys
into USM.  This is truly identical for OOB and for IB.  (there may be
other reasons for not wanting to pick one or the other, but
compatibility with USM can be done with either).  EK is less straight
forward, though it could be done that way but I'm not sure you'd want to.

Joe> If it is shown that another keying architecture is less invasive
Joe> to USM or the working group decides that protection mechanisms
Joe> within USM need to be replaced then I would reconsider my
Joe> opposition.

Can you explain *why* the other architectures are more invasive?

Lets take a concrete example.  Consider one instance of IBK that has
already been defined (just for example, I'm not arguing at the moment
that it's the right choice for an IBK implementation because it's not
relevant here): SBSM.  The results of the keying exchange of SBSM
could simply result in a USM principal ending up with the negotiated
keys.  Can you explain how that's affecting USM in some way that OOB
wouldn't be?

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 02:01:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRl2Q-0006ai-Qk; Sat, 30 Apr 2005 02:01:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRl2P-0006Z9-8A
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 02:01:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23082
	for <isms@ietf.org>; Sat, 30 Apr 2005 02:01:11 -0400 (EDT)
Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRlFb-0003Vr-6h
	for isms@ietf.org; Sat, 30 Apr 2005 02:14:52 -0400
Received: from h-68-164-242-11.snvacaid.dynamic.covad.net ([68.164.242.11]
	helo=oemcomputer)
	by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1DRl2L-00000X-00
	for isms@ietf.org; Fri, 29 Apr 2005 23:01:09 -0700
Message-ID: <009101c54d4a$4c16abc0$7f1afea9@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
References: <200504292026.j3TKQGq2020968@ginger.cmf.nrl.navy.mil><003901c54d29$c13fa9e0$7f1afea9@oemcomputer>
	<sdbr7xou2y.fsf@wes.hardakers.net>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Date: Fri, 29 Apr 2005 23:03:14 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Hi -

> From: "Wes Hardaker" <hardaker@tislabs.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <isms@ietf.org>
> Sent: Friday, April 29, 2005 7:51 PM
> Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third party
>

> >>>>> On Fri, 29 Apr 2005 19:10:17 -0700, "Randy Presuhn" <randy_presuhn@mindspring.com> said:
>
> >> I feel I must correct you here.  Kerberos requires relatively little
> >> work at the _agent_.  In fact, Kerberos servers are relatively simple,
> >> from both a management and programming aspect (we can debate what is
> >> "simple" and what is not, but I'm just talking about the relation
> >> between the manager and the agent).  The _manager_ is more complex.
> >> This is of course not true for all trusted third party systems.
>
> Randy> I don't see how things would be any simpler at an "agent"
> Randy> if it supports sending notifications as Informs.
>
> If you're making the assumption that USM will be used to protect the
> packets, then you're right.
...

Not just USM.  The recipient of the notification needs to know that it is
authentic, which means that the notification originator somehow has to
come to have the right bits to sign it.  The at the notification originator side,
we need to know on whose behalf the notification is to be sent, so the right
access control policy can be consulted to determine whether it will be
permitted to go on the wire.  If the notification originator doesn't pick up
these bits on its own (making it just as complex as the "manager"), the
notification subscriber would have to put them there.  This would get
especially ugly with large potential fan-in or short expiration times.

Randy




_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 06:16:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRp1F-0003PJ-BP; Sat, 30 Apr 2005 06:16:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRp1D-0003PE-3W
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 06:16:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25335
	for <isms@ietf.org>; Sat, 30 Apr 2005 06:16:12 -0400 (EDT)
Received: from galaxy.systems.pipex.net ([62.241.162.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRpEQ-0003Zx-IJ
	for isms@ietf.org; Sat, 30 Apr 2005 06:29:56 -0400
Received: from pc6 (1Cust131.tnt101.lnd4.gbr.da.uu.net [213.116.50.131])
	by galaxy.systems.pipex.net (Postfix) with SMTP id 2CE2FE00035C;
	Sat, 30 Apr 2005 11:15:59 +0100 (BST)
Message-ID: <004b01c54d64$b217cde0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <isms@ietf.org>, "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
References: <200504292026.j3TKQGq2020968@ginger.cmf.nrl.navy.mil>
Date: Sat, 30 Apr 2005 11:10:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [Isms] Kerberos cost was Keep the agent simple
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Ken

Where Kerberos is the third party to a end-user workstation and a server (FTP,
HTTP, SMTP, ...), then I have no issue with it; indeed, since its adoption by
Windows 200x Server, it is probably the industry standard (even if people think
Microsoft invented it:-(

But when the party is a desktop switch or access router with Telnet and TFTP and
not much else, that is when I see it as too much (and would make do with
something simpler, eg a pre-stored shared secret).  That is the context that
preoccupies me, where I look for a one touch solution.

Tom Petch

----- Original Message -----
From: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
To: <isms@ietf.org>
Sent: Friday, April 29, 2005 10:26 PM
Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party


> >Third party security- Kerberos - is stronger but that requires more work at
the
> >agent which it is my starting point not to have.
>
> <WG chair hat off>
>
> I feel I must correct you here.  Kerberos requires relatively little
> work at the _agent_.  In fact, Kerberos servers are relatively simple,
> from both a management and programming aspect (we can debate what is
> "simple" and what is not, but I'm just talking about the relation
> between the manager and the agent).  The _manager_ is more complex.
> This is of course not true for all trusted third party systems.
>
> Sometimes I think the amount of complexity required for authentication
> is constant, and the only real difference between different systems is
> where they choose to put the complexity.  I know that's not true, but
> it sure seems like it at times :-)
>
> --Ken
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 06:41:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRpPU-0008Bu-VM; Sat, 30 Apr 2005 06:41:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRpPT-0008Bp-4O
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 06:41:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26322
	for <isms@ietf.org>; Sat, 30 Apr 2005 06:41:16 -0400 (EDT)
Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103]
	helo=hosting.revelstone.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRpci-0004IE-5d
	for isms@ietf.org; Sat, 30 Apr 2005 06:55:01 -0400
Received: from localhost ([127.0.0.1] helo=aud)
	by hosting.revelstone.com with smtp (Exim 4.50)
	id 1DRpPD-0004sI-Qd; Sat, 30 Apr 2005 06:41:04 -0400
Date: Sat, 30 Apr 2005 06:41:06 -0400
From: Robert Story <rstory@freesnmp.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Message-ID: <20050430064106.126394a1@aud>
In-Reply-To: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.revelstone.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - freesnmp.com
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

On Thu, 21 Apr 2005 16:17:32 -0400 Ken wrote:
KH> What I would like to see is WG members express which architecture(s)
KH> they prefer

IBK- For
EK - Maybe
OOBK - oppose

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 07:38:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRqIx-000259-C2; Sat, 30 Apr 2005 07:38:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRqIw-00024w-45
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 07:38:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28916
	for <isms@ietf.org>; Sat, 30 Apr 2005 07:38:36 -0400 (EDT)
Received: from galaxy.systems.pipex.net ([62.241.162.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRqWB-000647-AI
	for isms@ietf.org; Sat, 30 Apr 2005 07:52:20 -0400
Received: from pc6 (1Cust131.tnt101.lnd4.gbr.da.uu.net [213.116.50.131])
	by galaxy.systems.pipex.net (Postfix) with SMTP id 3C46BE000314;
	Sat, 30 Apr 2005 12:38:22 +0100 (BST)
Message-ID: <00e601c54d70$355891c0$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Wes Hardaker" <hardaker@tislabs.com>
References: <20050428175901.C711EE00008F@hood.systems.pipex.net><001401c54cee$4fddf1c0$0601a8c0@pc6><sdvf651fej.fsf@wes.hardakers.net><006801c54cff$8c724e40$0601a8c0@pc6>
	<sd8y311asn.fsf@wes.hardakers.net>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Date: Sat, 30 Apr 2005 11:37:54 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

<inline>
Tom Petch

----- Original Message -----
From: "Wes Hardaker" <hardaker@tislabs.com>
To: "Tom Petch" <nwnetworks@dial.pipex.com>
Cc: <isms@ietf.org>
Sent: Saturday, April 30, 2005 12:24 AM
Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third
party


> >>>>> On Fri, 29 Apr 2005 23:06:27 +0200, "Tom Petch"
<nwnetworks@dial.pipex.com> said:
>
> Tom> But USM does not scale
>
> Never said otherwise.
>
> Your argument was that all trust should occur at the management
> station, though, and it should be configured with keys to the kingdom

Not so.  I take a third party security server as sine qua non and that server is
the third party to the end user workstation and to the server on which SNMP
manager runs.  The SNMP agent shares a secret with the security server, not with
the SNMP manager-server, and this secret is used to generate a session key; the
SNMP manager needs to know the session key as well so if the SNMP manager-server
is successfully attacked, then you lose security for the services on it - SNMP,
HTTP, SMTP, ....  Yes it can happen, but the loss of SNMP will be only one of
many headaches for the organisation.

If the agent is a server (FTP, HTTP, SMTP, ....), then of course it has all the
necessary infrastructure to be a party, with the SNMPmanager-server, to a third
party security server.

So I scale by having different degrees of security between agent and security
server, from pre-stored shared secret to Kerberos to ....


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 07:38:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRqIz-00025X-J5; Sat, 30 Apr 2005 07:38:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRqIx-000251-5G
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 07:38:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28921
	for <isms@ietf.org>; Sat, 30 Apr 2005 07:38:38 -0400 (EDT)
Received: from galaxy.systems.pipex.net ([62.241.162.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRqWD-000649-AQ
	for isms@ietf.org; Sat, 30 Apr 2005 07:52:21 -0400
Received: from pc6 (1Cust131.tnt101.lnd4.gbr.da.uu.net [213.116.50.131])
	by galaxy.systems.pipex.net (Postfix) with SMTP id D3E40E000350;
	Sat, 30 Apr 2005 12:38:28 +0100 (BST)
Message-ID: <00e701c54d70$3686b180$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>, <isms@ietf.org>
References: <200504292026.j3TKQGq2020968@ginger.cmf.nrl.navy.mil><003901c54d29$c13fa9e0$7f1afea9@oemcomputer><sdbr7xou2y.fsf@wes.hardakers.net>
	<009101c54d4a$4c16abc0$7f1afea9@oemcomputer>
Subject: Re: [Isms] Keep the agent simple;
	was RADIUS is not a trusted third party
Date: Sat, 30 Apr 2005 11:59:13 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Notifications I see as less of a concern; if we can safely perform set
operations on switches and routers, then I see that as a giant leap for network
management.  Securing notifications, in an unreliable network where polling is
the norm, I am less concerned with.  I struggle to think of a case where a
notification needs protection from disclosure; authentication, nice to have,
probably achieved, if required (big IF), by requiring the session to be in place
already, ie the manager polls the device regularly to keep the session alive and
so the authentication already exists - the agent is constrained to send a
notification only if a session exists.

Tom Petch

----- Original Message -----
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <isms@ietf.org>
Sent: Saturday, April 30, 2005 8:03 AM
Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party


> Hi -
>
> > From: "Wes Hardaker" <hardaker@tislabs.com>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > Cc: <isms@ietf.org>
> > Sent: Friday, April 29, 2005 7:51 PM
> > Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third
party
> >
>
> > >>>>> On Fri, 29 Apr 2005 19:10:17 -0700, "Randy Presuhn"
<randy_presuhn@mindspring.com> said:
> >
> > >> I feel I must correct you here.  Kerberos requires relatively little
> > >> work at the _agent_.  In fact, Kerberos servers are relatively simple,
> > >> from both a management and programming aspect (we can debate what is
> > >> "simple" and what is not, but I'm just talking about the relation
> > >> between the manager and the agent).  The _manager_ is more complex.
> > >> This is of course not true for all trusted third party systems.
> >
> > Randy> I don't see how things would be any simpler at an "agent"
> > Randy> if it supports sending notifications as Informs.
> >
> > If you're making the assumption that USM will be used to protect the
> > packets, then you're right.
> ...
>
> Not just USM.  The recipient of the notification needs to know that it is
> authentic, which means that the notification originator somehow has to
> come to have the right bits to sign it.  The at the notification originator
side,
> we need to know on whose behalf the notification is to be sent, so the right
> access control policy can be consulted to determine whether it will be
> permitted to go on the wire.  If the notification originator doesn't pick up
> these bits on its own (making it just as complex as the "manager"), the
> notification subscriber would have to put them there.  This would get
> especially ugly with large potential fan-in or short expiration times.
>
> Randy
>
>
>
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 17:11:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DRzFh-0007oV-NO; Sat, 30 Apr 2005 17:11:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DRzFd-0007nq-G5
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 17:11:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02864
	for <isms@ietf.org>; Sat, 30 Apr 2005 17:11:46 -0400 (EDT)
Received: from blaster.systems.pipex.net ([62.241.163.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRzSx-0008OJ-F6
	for isms@ietf.org; Sat, 30 Apr 2005 17:25:36 -0400
Received: from pc6 (1Cust224.tnt101.lnd4.gbr.da.uu.net [213.116.50.224])
	by blaster.systems.pipex.net (Postfix) with SMTP id 85831E0000E4;
	Sat, 30 Apr 2005 22:11:33 +0100 (BST)
Message-ID: <02b301c54dc0$477c1160$0601a8c0@pc6>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: <isms@ietf.org>, "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
References: <200504212017.j3LKHUQO028810@ginger.cmf.nrl.navy.mil>
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
Date: Sat, 30 Apr 2005 22:00:37 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

Out of Band keying is my preference.

The discussions of the past few months have shown (what I think
. of as) flaws in
all the approaches and I now think Out of Band has the greatest flexibility to
produce a workable proposal.

Tom Petch
----- Original Message -----
From: "Ken Hornstein" <kenh@cmf.nrl.navy.mil>
To: <isms@ietf.org>
Sent: Thursday, April 21, 2005 10:17 PM
Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture


> ISMS members,
>
> There's been a lot of discussion recently on the mailing list about the
> pros and cons of different security models.  I think the discussion has
> been good, but unfortunately I don't think it's getting any closer to a
> consensus (I thank Robert for trying to draw things closer;
> unfortunately Juergen and I have been rather busy off-line, and I
> apologize for that).  I know that some on the mailing list have
> expressed a preference for choosing a security protocol first, but
> we've been tasked with choosing the architecture first, and I believe
> that is the appropriate approach.
>
> Anyway, I'd like to call for a consensus on the security architecture.
> As we all know, the three choices are:
>
> - Out of band keying (the architecture used by EUSM)
> - In-bakd keying (the architecture used by SBSM)
> - Encapsulation keying (the architecture used by TLSM)
>
> What I would like to see is WG members express which architecture(s)
> they prefer (you can choose more than one, but please, don't choose all
> three).  Please feel free to state your reasons for your choices, but
> in the interests of reaching consensus in a reasonable timeframe, I am
> asking that WG members please refrain from commenting on other people's
> choices unless they feel that the person has stated a fact which is
> obviously wrong.
>
> Thanks for your time,
>
> --Ken
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 18:44:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DS0hi-00068p-I7; Sat, 30 Apr 2005 18:44:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DS0hg-00068k-Nv
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 18:44:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08333
	for <isms@ietf.org>; Sat, 30 Apr 2005 18:44:49 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DS0v1-0002oY-Kr
	for isms@ietf.org; Sat, 30 Apr 2005 18:58:41 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3UMiFoF012343; 
	Sat, 30 Apr 2005 15:44:15 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3UMiDrI026434;
	Sat, 30 Apr 2005 15:44:13 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3UMiCG0026431; Sat, 30 Apr 2005 15:44:13 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Sat, 30 Apr 2005 15:44:12 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Tom Petch <nwnetworks@dial.pipex.com>
Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third
	party
In-Reply-To: <00e701c54d70$3686b180$0601a8c0@pc6>
Message-ID: <Pine.LNX.4.10.10504301539380.25093-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: isms@ietf.org
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

HI,

Tom - notification delivery is not so simple. The best kept secret
is SNMP informs. However, configuring their use (authNoPriv or authPriv)
is quite difficult. If one of the side effects of the a new
security model is the secure informs are actually easy to use,
I predict that they will see quite a bit more usage.

Note, I believe that it is not generally appropriate to
use the same session for request operations as that is
used for general notification delivery.


On Sat, 30 Apr 2005, Tom Petch wrote:
> Notifications I see as less of a concern; if we can safely perform set
> operations on switches and routers, then I see that as a giant leap for network
> management.  Securing notifications, in an unreliable network where polling is
> the norm, I am less concerned with.  I struggle to think of a case where a
> notification needs protection from disclosure; authentication, nice to have,
> probably achieved, if required (big IF), by requiring the session to be in place
> already, ie the manager polls the device regularly to keep the session alive and
> so the authentication already exists - the agent is constrained to send a
> notification only if a session exists.
> 
> Tom Petch
> 
Regards,
/david t. perkins



_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms



From isms-bounces@lists.ietf.org Sat Apr 30 19:52:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DS1lC-0006GJ-7g; Sat, 30 Apr 2005 19:52:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DS1lA-0006GB-Rp
	for isms@megatron.ietf.org; Sat, 30 Apr 2005 19:52:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11482
	for <isms@ietf.org>; Sat, 30 Apr 2005 19:52:29 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DS1yW-0004sl-Fq
	for isms@ietf.org; Sat, 30 Apr 2005 20:06:21 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3UNqGoF002650; 
	Sat, 30 Apr 2005 16:52:17 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3UNqEm5007794;
	Sat, 30 Apr 2005 16:52:14 -0700
Received: from localhost (dperkins@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	j3UNqEZ6007791; Sat, 30 Apr 2005 16:52:14 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Sat, 30 Apr 2005 16:52:14 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: isms@ietf.org
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
In-Reply-To: <02b301c54dc0$477c1160$0601a8c0@pc6>
Message-ID: <Pine.LNX.4.10.10504301634580.25093-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: 
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@lists.ietf.org
Errors-To: isms-bounces@lists.ietf.org

HI,

My choice is in-band-keying, since I believe that it best
addresses the issue of reducing the operational cost of
deploying and using SNMPv3.

I believe that with in-band-keying there will not be
additional configuration requirements that I believe
out-of-band-keying has. I believe that in-band-keying
will be the most flexible in using the existing
unmodified credentials that are held by users and
servers using other authentication infrastructures.
I don't believe that encapsulation-keying will be
able to be adapted to use all the major existing
authentication infrastructures.

I believe that there is no difference between in-band
and out-of-band-keying with reuse of security protocols
used in USM for message integrity checking and message
encryption.

I believe I've seen many messages where the author has:
1) solved (or optimized) a different problem than that
   identified in the WG charter
2) has been mistaken about the characteristics of
   one approach vs another. For example, all approaches
   can use Radius technology for authentication.
   Believing that only one approach can use Radius
   is a mistake, and can result in a faulty conclusion.
3) stated conclusions without describing how that
   conclusion was reached

So, I hope that my choice suffers no faults from bad
data, faulty reasoning, or inadequate description.
But if it does, please let me know, and I will change
my choice if needed.

Regards,
/david t. perkins


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms