Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture

From: Ken Hornstein <[email-masked]>
Date: Thu, 21 Apr 2005 16:17:32 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 Apr 2005 16:55:10 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ken Hornstein
> Sent: Thursday, April 21, 2005 4:18 PM
> To: [email-masked]
> Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> ISMS members,
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Apr 2005 23:33:32 +0200

> 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

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Apr 2005 15:33:55 -0700

>>>>> On Thu, 21 Apr 2005 16:17:32 -0400, Ken Hornstein <[email-masked]> 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.

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 Apr 2005 22:38:05 -0400

Hi,

In this comment,

> 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

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 26 Apr 2005 23:21:53 +0200

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        [email-masked]       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

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 26 Apr 2005 23:52:04 +0200

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 26 Apr 2005 18:46:04 -0400

Hi,

EK - yes
IB - maybe
OOB - maybe

dbh 

> [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Tuesday, April 26, 2005 5:22 PM
> To: [email-masked]
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> Dear all,
>

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 26 Apr 2005 17:54:11 -0700

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!

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Apr 2005 06:28:43 -0400

Preference against OOBK.

---

From: Marcus Leech <[email-masked]>
Date: Thu, 28 Apr 2005 10:06:52 -0400

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                          [email-masked]

---

From: "Wayne Kading" <[email-masked]>
Date: Fri, 29 Apr 2005 17:12:15 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Quittek
Sent: Tuesday, April 26, 2005 4:22 PM
To: [email-masked]
Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture

Dear all,

Thanks,

    Juergen

---

From: Robert Story <[email-masked]>
Date: Sat, 30 Apr 2005 06:41:06 -0400

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

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 30 Apr 2005 22:00:37 +0200

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

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 30 Apr 2005 16:52:14 -0700 (PDT)

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