IETF Logo Mail Archive

Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 06 May 2010 06:34 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B607C3A6ACE; Wed, 5 May 2010 23:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_40=-0.185, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BgZ69B-WBoq; Wed, 5 May 2010 23:34:14 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A12C63A6A6B; Wed, 5 May 2010 23:34:14 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B470C0024; Thu, 6 May 2010 08:34:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GONtMPtIre76; Thu, 6 May 2010 08:34:00 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F439C000C; Thu, 6 May 2010 08:33:59 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3225D11F1D83; Thu, 6 May 2010 08:33:57 +0200 (CEST)
Date: Thu, 06 May 2010 08:33:57 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Wes Hardaker <wjhns1@hardakers.net>
Message-ID: <20100506063357.GA55813@elstar.local>
Mail-Followup-To: Wes Hardaker <wjhns1@hardakers.net>, David Harrington <ietfdbh@comcast.net>, "iesg@ietf.org" <iesg@ietf.org>, "isms@ietf.org" <isms@ietf.org>
References: <sdaase140y.fsf@wjh.hardakers.net> <097301caeca7$c385a650$0600a8c0@china.huawei.com> <sdhbmmx7eg.fsf@wjh.hardakers.net> <097801caecad$61936f30$0600a8c0@china.huawei.com> <sdvdb1vdmp.fsf@wjh.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <sdvdb1vdmp.fsf@wjh.hardakers.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "iesg@ietf.org" <iesg@ietf.org>, "isms@ietf.org" <isms@ietf.org>
Subject: Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm
X-BeenThere: isms@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isms>
List-Post: <mailto:isms@ietf.org>
List-Help: <mailto:isms-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2010 06:34:15 -0000

On Thu, May 06, 2010 at 06:49:02AM +0200, Wes Hardaker wrote:

> DH> PKIX would not be the right place to define how to ***map them to
> DH> SNMPv3*** security levels.
> 
> I think I misread a sentence early on and I apologize for that because I
> missed the original point.
> 
> Defining a mapping table to security levels is technically possible and
> would probably look something close to:
> 
>   |------------------------------+-------------------------------|
>   | TLS Suite (index(es))        | securityLevel (output column) |
>   |------------------------------+-------------------------------|
>   | TLS_RSA_WITH_AES_128_CBC_SHA | authPriv                      |
>   | TLS_NULL_WITH_NULL_NULL      | noAuthNoPriv                  |
>   | TLS_RSA_WITH_NULL_SHA256     | authNoPriv                    |
>   | ...                          | ...                           |
>   |------------------------------+-------------------------------|
> 
> I don't think it would be a complex table.  But we decided not to go
> there and simply declare than "NULL" must not be used to fulfill an
> "auth" or "priv" flag (which the document already says).

And this approach seems to be consistent with what RFC 5592 does.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

v2.23.0 | Report a Bug | By Email