Subject: [Isms] My feedback on draft-ietf-isms-proposal-comparison-00.txt

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 21 Feb 2005 11:11:07 -0800

Co-workers,

I am grateful to the authors of the "Comparison of Proposals..."
document for providing a catalyst for our discussion, despite my
disappointment in their analysis.

Specifically, in Section 2.4.1 they mention only two current
disadvantages to the USM. This surprised me because I thought that the
WG had formed a pretty solid consensus on the need to address at least a
third issue: Session security (i.e., SNMPv3 privacy key security).
Certainly, one of the proposals, TLSM, was centrally and primarily
addressing this important issue. Thus, it is difficult for me to
understand how the authors could have overlooked this key issue as an
additional discriminator for making their recommendation. In any case,
the authors, while not acknowledging this third issue to be a problem
nor using it as a discriminator, nevertheless considered it to be
important enough to included as Section 3.4 (Sessions) within their
recommendation. I find this disconnect to be very puzzling.

>From where I sit, I recommend:
1) If EUSM is chosen as the starting place, that it be extended to
include additional authentication infrastructures (i.e., Kerberos and
PKI really must also be on the list) AND it be supplemented to more
explicitly address Session security. For example, the group might want
to consider merging EUSM with aspects of TLSM as a possible starting
point.

2)However, I personally believe that SBSM is the more complete solution
and offers a framework to scratch all of the articulated itches (e.g.,
the above 3 USM issues as well as my own prioritized list of 6 issues).
I didn't notice an answer on the list to Wes' query below, but it seems
to me that if that issue is indeed is the primary reason that the did
authors not recommend SBSM as they stated, then an answer really needs
to be provided (e.g., I puzzled by the same question as Wes asked). 

The WG can either proceed bottom up or top down as a mechanism for
proceeding from here. Taking EUSM, which is already deployed, and
enhancing it to scratch all of the itches, could be a possible
bottoms-up approach for the WG. However, a preferable Top-down approach
(e.g., for Top-down people like me) is to take the solution with the
most complete architectural foundation, SBSM, and define it to
successive degrees of specificity. 

It's the WG's call which approach is used. However, the purpose of this
email is to state that addressing/solving SNMPv3 session issues/problems
*MUST* also be a key design issue for this WG: The ultimate WG's
recommendations need to be extended to also address session issues.

--Eric

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 
Sent: Tuesday, February 15, 2005 3:34 PM
To: [email-masked]
Subject: [Isms] clarification: protocol on the wire unchanged

You know, many people say its a plus to have the protocol on the wire
unchanged (IE, the security parameters format is still USM).  I've yet
to find someone that can explain the rational behind that?  Some have
argued code change required, but that doesn't make sense since you have
to write code to support the new integration with whatever the new
keying mechanism is.  I don't buy any argument that all such integration
code will be less than modifying the security parameters fields in all
cases (unless of you course you don't have a set of BER routines
available, but we all know everything does already).  In short, all 3
protocols require new code in both the manager and the agent.  Some of
the protocols require new protocol extensions in other protocols (EG
EUSM's needed modifications to Radius) and new code in the deployment
base of those new protocols on both the manager and the agent (err...
CG and CR) side of the transaction.

Don't get me wrong, I'm not arguing that we should change it if we don't
have to.  I fail to see the "advantages" that people state are there for
not changing it.

(especially since all solutions to date will require new security
protocol identifies anyway, so it's not like you can take any solutions
protocol and throw it through an unmodified SNMPv3 stack in the first
place (unless such a stack is already broken in that it ignores the
security protocol identifier in the packet today)).

-- 
Wes Hardaker
Sparta

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

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