Subject: [Isms] SNMP over (D)TLS draft available for review

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Oct 2009 16:04:09 -0700

As you probably saw from the official draft announcement, a new copy of
the SNMP over (D)TLS draft is available from:

  http://tools.ietf.org/html/draft-ietf-isms-dtls-tm-01

A diff from the previous version can be found here:

  http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-isms-dtls-tm-01.txt

The -01 version reflects all outstanding issues that I'm aware of.  It
would be good if WG participants could review the document and/or
changes prior to the WG meeting in Hiroshima and list any issues you
have with the draft so we can use the meeting time to discuss any of
them that require a face-to-face meeting.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Hamid Mukhtar <[email-masked]>
Date: Wed, 28 Oct 2009 14:58:51 +0900

Dear Wes,

In section 3.1.2 its mentioned that

>   the NULL integrity and encryption algorithms MUST NOT be used to fulfill
>   security level requests for authentication or privacy.
>   Implementations MAY choose to force (D)TLS to only allow
>   cipher_suites that provide both authentication and privacy to
>   guarantee this assertion.

IMO the requirement, as stated currently, may have to be changed to
consider authentication-only cipher suites (with no encryption)
[RFC4785].

On Wed, Oct 28, 2009 at 8:04 AM, Wes Hardaker <[email-masked]> wrote:
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 28 Oct 2009 09:20:57 -0700

>>>>> On Wed, 28 Oct 2009 14:58:51 +0900, Hamid Mukhtar <[email-masked]> said:

>> guarantee this assertion.

HM> IMO the requirement, as stated currently, may have to be changed to
HM> consider authentication-only cipher suites (with no encryption)
HM> [RFC4785].

First, thanks for reviewing the text.

The intent of that text is to allow for the following combinations:

   |                | noAuthNoPriv | authNoPriv | authPriv  |
   | Authentication | NULL         | something* | something |
   | Encryption     | NULL         | NULL       | something |

But to explicitly disallow:

   |                | noAuthNoPriv | authNoPriv | authPriv |
   | Authentication |              | NULL       | NULL     |
   | Encryption     |              |            | NULL     |
     
So the text is not intended to prohibit what you're describing.
Functionally what you want is the * above (in the allowed table), where
the authentication algorithm is not NULL.  The actual algorithm would
be an authenticating encryption algorithm, but since it's doing
authentication it's functionally acting "in that slot".

So, I don't think the intent of the text needs to change but if the
wording is unclear then the text should be updated to make it explicitly
clear.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 29 Oct 2009 10:30:12 +0900

> wording is unclear then the text should be updated to make it explicitly

Yes, the wording might cause confusion. I think its better to be more explicit.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 29 Oct 2009 08:07:34 -0700

>>>>> On Thu, 29 Oct 2009 10:30:12 +0900, Hamid Mukhtar <[email-masked]> said:

HM> Yes, the wording might cause confusion. I think its better to be
HM> more explicit.

I'll look at rewording the text.  Thanks for the comments about it.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Fri, 30 Oct 2009 10:01:05 -0400

Wes,

The tlstmCompliance module is not listing each group with a compliance
description and was wondering if the implementation of notifications are
optional or mandatory.

- Andy Donati

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wes Hardaker
Sent: Tuesday, October 27, 2009 7:04 PM
To: [email-masked]
Subject: [Isms] SNMP over (D)TLS draft available for review

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-isms-dtl
s-tm-01.txt

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 Oct 2009 07:44:52 -0700

>>>>> On Fri, 30 Oct 2009 10:01:05 -0400, "Donati Andrew-MGIA0477" <[email-masked]> said:

DA> The tlstmCompliance module is not listing each group with a compliance
DA> description and was wondering if the implementation of notifications are
DA> optional or mandatory.

The 4th mandatory group of the the "tlstmComlpiance" object is
"tlstmNotificationGroup" which contains the "tlstmServerCertNotFound"
and "tlstmServerAuthFailure" notification definitions, which are the
only two defined NOTIFICATION-TYPEs.  So they're definitely listed.  Or
are you indicating that there is no surrounding human-readable text
describing the requirements?
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Fri, 30 Oct 2009 11:18:43 -0400

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 10:45 AM
To: Donati Andrew-MGIA0477
Cc: Wes Hardaker; [email-masked]
Subject: Re: SNMP over (D)TLS draft available for review - Group
compliance statements for notifications

>>>>> On Fri, 30 Oct 2009 10:01:05 -0400, "Donati Andrew-MGIA0477"
<[email-masked]> said:

DA> The tlstmCompliance module is not listing each group with a 
DA> compliance description and was wondering if the implementation of 
DA> notifications are optional or mandatory.

WH> Or are you indicating that there is no surrounding human-readable
text describing the requirements?

Yes.  They are indeed listed in the in the 'MANDATORY-GROUPs' clause,
but was looking for additional 'GROUP' and 'DESCRIPTION' clauses for
each group.  The 'DESCRIPTION' clause can contain information on whether
or not the group is mandatory or optional to implement, as illustrated
in rfc2580.  When the discussion began on adding tlstm notifications,
there may have been some consideration of not making implementers use
them if they did not have a need for it and was wondering what the final
decision was.

- Andy

---

From: "David Harrington" <[email-masked]>
Date: Fri, 30 Oct 2009 11:49:42 -0400

I think it makes sense to mandate them in implmentations, so they are
available if an operator wants to use them.

dbh 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Donati Andrew-MGIA0477
> Sent: Friday, October 30, 2009 11:19 AM
> To: Wes Hardaker
> Cc: [email-masked]
> Subject: Re: [Isms] SNMP over (D)TLS draft available for 
> review - Groupcompliance statements for notifications
> 
>  
>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 Oct 2009 09:06:44 -0700

>>>>> On Fri, 30 Oct 2009 11:18:43 -0400, "Donati Andrew-MGIA0477" <[email-masked]> said:

DA> Yes.  They are indeed listed in the in the 'MANDATORY-GROUPs' clause,
DA> but was looking for additional 'GROUP' and 'DESCRIPTION' clauses for
DA> each group.  The 'DESCRIPTION' clause can contain information on whether
DA> or not the group is mandatory or optional to implement, as illustrated
DA> in rfc2580.

Ah, so you're not asking for clarification.  You want the notifications
to be removed from the mandatory clause.  If you read 5.4.1 of RFC2580
carefully you'll see that as-is the MIB describes conformance
requirements perfectly: the notifications are required.

We'll see what the results of the discussion are with respect to whether
others agree with you that they should be optional and removed from the
MANDATORY-GROUPS list.  (David, eg, seems to think they should stay).
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Fri, 30 Oct 2009 12:35:39 -0400

Wes,
I see what you are saying and actually vote for them to stay mandatory
as I believe that they are important to all network administrators.  I
wanted to clarify where it stood because there was some discussion on
making it an optional implementation when the topic was initially
brought up.
- Andy 

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 12:07 PM
To: Donati Andrew-MGIA0477
Cc: Wes Hardaker; [email-masked]
Subject: Re: SNMP over (D)TLS draft available for review - Group

>>>>> On Fri, 30 Oct 2009 11:18:43 -0400, "Donati Andrew-MGIA0477"
<[email-masked]> said:

DA> Yes.  They are indeed listed in the in the 'MANDATORY-GROUPs' 
DA> clause, but was looking for additional 'GROUP' and 'DESCRIPTION' 
DA> clauses for each group.  The 'DESCRIPTION' clause can contain 
DA> information on whether or not the group is mandatory or optional to 
DA> implement, as illustrated in rfc2580.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 Oct 2009 09:45:47 -0700

>>>>> On Fri, 30 Oct 2009 12:35:39 -0400, "Donati Andrew-MGIA0477" <[email-masked]> said:

DA> I see what you are saying and actually vote for them to stay mandatory
DA> as I believe that they are important to all network administrators.

Ah, ok.  Then I think there is no longer a problem to resolve, correct?
As we now have no one vying for making them optional and the current
objects definitely mark them as mandatory.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Fri, 30 Oct 2009 12:47:19 -0400

Wes,

Just a few more questions on notifications ... 

1.  tlstmServerAuthFailure notification.
Will it be helpful for network administrators to know the current count
of how many times the presented server certificate is invalid in each
tlstmServerAuthFailure notification?  If so, it may be helpful to have
tlstmSessionInvalidServerCertificates as an additional binding
especially if this object is the trigger.

2.  Standard authentication failure notification.
There might have been some previous discussions about possibly using the
standard authenticationFailure trap for tlstm authentication failures.
Will this be used or will there be no autonomous messages for these
events?

3. tlstmServerCertNotFound
Should there be scalar object that serves as a counter for this event? 
If implemented, this object can be added to this notification.

- Andy Donati