Subject: Re: [Isms] Latest Proposed Charter Text

From: "David Harrington" <[email-masked]>
Date: Fri, 1 May 2009 08:33:37 -0400

Hi,

(I have copied this to OPSAWG since that WG is discussed later in this
email.)

I am not sure how much difference will be encountered between TLS and
DTLS support.
Trying to do both in one document could be confusing unless there is
clear separation.
The elements of procedure are especially tricky to get right in ISMS
documents.
This might be simpler now that we did the SSH TM, whose client/server
issues will be similar.
I would be interested in understanding which sections in the current
document would be impacted by adding TLS to the document.
Will it be possible to write most sections in a manner that is
independent of the TLS vs DTLS choice, and then capture the
differences in separate appendices, or will all the sections,
especially EOP, end up with lots of conditional clauses?

We need to develop standards that are clear and unambiguous.
If putting the two into the same document seriously hurts the clarity,
then it should be done as two documents.

I think the single most important work to be done following a
recharter is AAA-aware access control.
Chartering for only that work will probably get it done faster, and
that will complete the initial vision of ISMS.
The TLS/DTLS work could be done as individual submissions (or is that
independent submissions? or AD-sponsored?)
I hope Wes's documents are very close to complete, since he has done
them in parallel with the SSH work.
I would hate to see the WG get bogged down with the TLS/DTLS TMs and
not get AAA-aware AC done quickly.
I support having TLS and DTLS TMs, because I see growinfg demand for
TLS and DTLS transport, but I am not sure there is compelling demand
for them at this time.

My suggestion would to be recharter for AAA-aware AC, with tight
milestones - on the order of six to nine months.
When that work is complete, then take on the TLS/DTLS work.

-- consistency --

I will note that there is a Proposed Standard for syslog/TLS, and
netconf/TLS is in the RFC Editor's queue. There are two proposals for
syslog over DTLS. The authors of the two proposals are discussing
merging the two documents.

Syslog WG is also debating whether to recharter. The syslog chairs and
OPS/SEC ADs are discussing whether to do DTLS support in the syslog WG
or in OPSAWG or a new syslog-ops WG. The syslog/TLS standard already
discusses at length how TLS should be used, including cyphers,
certificates, fingerprinting, what to do when a CA is unavailable, and
so on, and the newer DTLS draft simply points to the syslog over TLS
standard for the TLS processing. The newer syslog over DTLS draft just
describes the differences between DTLS and TLS processing, and
specific changes to syslog transport. And that can be seen as syslog
OPS work, not syslog SEC work. 

If both syslog over DTLS(TLS) and SNMP over DTLS(TLS) were done in
OPSAWG, there might be a greater chance of consistent DTLS(TLS)
security, and Wes's draft might be able to simply point to the TLS
security processing in the syslog over TLS Proposed Standard as well.
If Wes and the syslog authors separated the DTLS-specific differences
into a separate document, possibly published in the sylog-sec WG, then
both syslog and SNMP transport models could point to that draft. Of
course, the syslog drafts are way simpler because they don't need
RFC3411 compatibility.

The newer of the sylog/DTLS drafts was deliberately made consistent
with the syslog/TLS Proposed Standard, and was made consistent with
Wes's DTLS-specific support. The Netconf/TLS draft was also made
consistent with the syslog/TLS draft. I think Wes tried to keep his
draft consistent with other NM/DTLS work going on. 

So draft consistency work has already been done; it has just already
been done by individual editors rather than as a deliberate SEC-area
and OPS-area approach. ISMS was originally started because operators
want to be able to utilize their existing security systems rather than
having SNMP-specific and syslog-specific security infrastructures. By
making the TLS and DTLS layers consistent for NM interfaces, we help
accomplish that goal. And if we separate the TLS/DTLS support from the
NM transport models, we can have the SEC area maintain the security
protocol applicability, while OPS maintains the NM bindings.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Thursday, April 30, 2009 4:34 PM
> To: [email-masked]
> Subject: [Isms] Latest Proposed Charter Text
> 
> 
> Enclosed is the last charter text (which received no comments 
> after the
> last submission).
> 
> The only outstanding question I can think of is whether there was
> agreement to include TLS into the DTLS draft or not.  Everyone in
the
> discussion seemed to be "on the fence" so I didn't include it in the
> text below, taking that as "not consensus at this time".  If 
> people wish
> TLS to be taken into account, now is the time to speak up.
> 
> 
> 
> Integrated Security Model for SNMP (isms)
> 
> Last Modified: XXXX
> 
> Additional information is available at tools.ietf.org/wg/isms
> 
> Chair(s):
> * Juergen Schoenwaelder <[email-masked]>
> 
> Security Area Director(s):
> * Tim Polk <[email-masked]>
> * Pasi Eronen <[email-masked]>
> 
> Security Area Advisor:
> * Pasi Eronen <[email-masked]>
> 
> Mailing Lists:
> 
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> In Body: in body: (un)subscribe
> Archive: 
> http://www.ietf.org/mail-archive/working-groups/isms/current/m
> aillist.html
> 
> Description of Working Group:
> 
> The Simple Network Management Protocol version 3 (SNMPv3) provides
> message security services through the security subsystem.
Previously
> the ISMS Working Group defined a Transport Subsystem definition, a
new
> Transport Security Model, and a Secure Shell Transport Model and a
> method for authenticating SNMPv3 users via the Remote Authentication
> Dial-In User Service (RADIUS).  The initial body of work to be
> tackled by the working group involved only these pieces.
Additional
> work on other transport models and other security extensions were to
> wait until the initial transport architecture and defining documents
> were completed.
> 
> It is now possible to authenticate SNMPv3 messages via a RADIUS when
> those messages are sent over the newly defined SSH transport. 
>  However,
> it still remains impossible to centrally authorize a given SNMP
> transaction as on-device pre-existing authorization configuration is
> still required.  In order to leverage a centralized RADIUS service
to
> its full extent, the access control decision in the Access Control
> Subsystem needs to be based on authorization information received
from
> RADIUS as well.  The result will be an extension to the View-based
> Access Control Model (VACM), to obtain authorization 
> information for an
> authenticated principal from RADIUS.  The authorization 
> information will
> be limited to mapping the authenticated principal to existing access
> control polices, defining session timeouts, and similar session
> parameters.  This mechanism will not provision the detailed access
> control rules.
> 
> Additionally, new work will be undertaken to define a DTLS-based
> transport that can offer support for environments that prefer
> certificate authentication and/or datagram-based transmissions.
> Certificate based authentication is desirable for many 
> environments with
> a centralized authentication service.  Datagram based 
> transports may be
> desired for environments where TCP performance suffers because of
> network anomalies (e.g. high packet loss rates).  A 
> DTLS-based transport
> would offer a solution that addresses both of these situations.
> 
> The current goal of the ISMS working group is two-fold: to develop a
> method for allowing for access control decisions to be based on
> information provide by an AAA provisioning service and to develop a
> DTLS-based Transport Model.
> 
> The new work must not modify any other aspects of SNMPv3 protocol as
> defined in STD 62 (e.g., it must not create new PDU types).
> 
> The working group will cover the following work items:
> 
>   - Specify a mechanism to support centralization of SNMPv3 Access
>     Control decisions by means of a RADIUS-provisioned
>     username-to-groupname dynamic mapping, that would provide 
> a binding
>     between a user and preconfigured VACM policies via 
> dynamic additions
>     to the securityToGroupname table. Additionally, specify a 
> time limit
>     for access decisions, and such a time limit should be used to
>     garbage collect expired dynamic securityToGroup mappings.
> 
>   - Specify the DTLS transport for SNMP.
> 
> Goals and Milestones:
> Jul 2009        Publish initial documentation on the DTLS 
> transport for SNMP
> Jul 2009        Publish initial documentation for the 
> centralized access control
> Jan 2010        Submit documentation on the DTLS transport 
> for SNMP to IESG
> Jan 2010        Submit documentation for the centralized 
> access control to IESG
> 
> -- 
> Wes Hardaker
> Cobham Analytic Solutions
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 1 May 2009 09:17:51 -0400

David Harrington writes...

> recharter is AAA-aware access control.

I concur.

> that will complete the initial vision of ISMS.

This seems like a non sequitur.  I don't see any serialization of work that
would occur because of scarce resources.

> security processing in the syslog over TLS Proposed Standard as well.

That might be true.  OTOH, is there any benefit in doing that work in a
Security Area WG rather than an Operations & Management Area WG?
 
> protocol applicability, while OPS maintains the NM bindings.

Certainly there is some benefit to operators in cross-protocol operational
consistency.  Of course I've found that obtaining that kind of consistency
usually slows things down.  Not that speed of completion is the only driving
factor, of course.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 1 May 2009 10:29:03 -0400

Hi, 

> would occur because of scarce resources.

We only have about six active people in this WG, and they will be
involved in both activities.
If the AAA-AC becomes in any way dependent on the TLS/DTLS work, I
would hate to see the AAA delayed.
Maybe you are right. AAA-AC is in the AC subsystem, while TLS/DTLS is
in the transport subsystem.
Maybe the work will be orthogonal.
> Security Area WG rather than an Operations & Management Area WG?

As Pasi pointed out in the syslog/DTLS discussions, the DTLS
processing 
should be basically the same as the TLS processing. The dufferences
are 
generally minor at the secureity level. But the OPS-level
applicability 
and bindings can be substantially different.

If you consider these as two different related pieces, much as SSHTM
and 
the SSH processing are distinct, then it would seem to make sense to
me
to have the DTLS processing be done in the SEC area. Some of the work
is 
really about understanding the applicability for different tasks. That

was a major issue for SSTM, as we had to figure out whether
notification
originators should be clients or servers. That could get built into
the
SEC area standards and/or applicability statements for how to use
TLS/DTLS 
for NM.

Then the OPS area can deal with writing bindings between specific NM 
protocols and the underlying, standardized DTLS and TLS layer
services.

> usually slows things down.  Not that speed of completion is 

It could slow things down, BUT ... much of that work has already been
done
because the authors of the related documents (Wes, Linda, Rainer, Tom,
Badra),
have worked to be fairly consistent already.

Each NM protocol community that needs secure transport has already
completed its work. 
The remaining TLS and DTLS work is optional to handle less immediate
use cases. A
little delay for the sake of consistency can probably be accommodated
without problems.

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 01 May 2009 11:54:43 -0700

DH> I am not sure how much difference will be encountered between TLS and
DH> DTLS support.  Trying to do both in one document could be confusing
DH> unless there is clear separation.

Most of TLS and DTLS are identical in functionality.  The certificate
handling, etc would be identical and wouldn't change.

What would change:

1) The elements of procedure.  You're right that it's tricky to get
   right.  The good news is that I think the current draft already
   reflects a lot of what would be needed.  I don't think you've read
   the current EOPs yet, but if you go look at it you'll notice that
   right now it already separates out DTLS over UDP from DTLS over SCTP
   where it makes sense to do so.  And that's really only for
   identifying incoming packets, because TLS and DTLS don't have an
   internal session identifier.  Everything else is identical.  Really,
   TLS would be a similar case to SCTP as both TCP and SCTP are stream
   based protocols that have internal kernel identification procedures.

2) We'd need another domain/address format.  This is trivial.

3) Various wording would need to be cleaned up to include TLS everywhere
   as appropriate.  I don't think this would be difficult, but it would
   require a complete draft review.  Something is likely to be needed
   anyway.

DH> Will it be possible to write most sections in a manner that is
DH> independent of the TLS vs DTLS choice, and then capture the
DH> differences in separate appendices, or will all the sections,
DH> especially EOP, end up with lots of conditional clauses?

I think most of the draft would be very similar to what it is now, with
slightly more generic wording.  The only spot I can think of that needs
extra care is the EOP.  But I think the existing EOP is close to what we
want anyway for how TLS would need to be added.

DH> I think the single most important work to be done following a recharter
DH> is AAA-aware access control.

You may certainly think that.

DH> Chartering for only that work will probably get it done faster, and that
DH> will complete the initial vision of ISMS.

But I'm not sure that the community thinks your prioritization there is
right.  From the meeting minutes:

   |            |  DTLS | Radius |
   | Authors    | 1 [1] |  0 [2] |
   | Reviewers  |     6 |      5 |
   | Supporters |     9 |      6 |

[1] it wasn't asked if anyone else wanted to help edit
[2] Editors have since agreed to work on it

Now, not everyone was there and certainly the authors of the radius
draft alone pick the numbers up a bit in the right most column.  But I
don't think, based on the numbers, that your weighing of importance is
anything other than your own personal preference.

I also don't think that one document would hamper the other.  I'm not
sure they would.  In fact, I'm fairly positive they wouldn't.  They're
even on different time schedules according to the draft charter and I
don't think that if you wished to drop the DTLS work that anyone would
be willing to move the other schedule dates for AAA mappings up.
They're very independent drafts.

DH> I support having TLS and DTLS TMs, because I see growing demand for
DH> TLS and DTLS transport, but I am not sure there is compelling demand
DH> for them at this time.

You see demand but no demand???  Huh?

As an implementer, I've seen demand for DTLS.  I've never seen demand
for AAA support.

DH> I think Wes tried to keep his draft consistent with other NM/DTLS work
DH> going on.

I spent most of my time keeping the SNMP/DTLS work consistent with the
other ISMS work (TSM and SSH).

-- from your other message --

DH> If the AAA-AC becomes in any way dependent on the TLS/DTLS work, I
DH> would hate to see the AAA delayed.

I don't see how that would ever happen.

DH> If you consider these as two different related pieces, much as SSHTM
DH> and the SSH processing are distinct, then it would seem to make
DH> sense to me to have the DTLS processing be done in the SEC area.

I don't see the purpose of considering moving it.  The expertise for TLS
is here in the security area.  The current ADs already have knowledge of
the whole ISMS related solution and architecture.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 6 May 2009 12:36:18 +0200

From: "David Harrington" <[email-masked]>
To: "'Dave Nelson'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 01, 2009 4:29 PM
> As Pasi pointed out in the syslog/DTLS discussions, the DTLS processing
> should be basically the same as the TLS processing. The dufferences  are
> generally minor at the secureity level. But the OPS-level applicability

I agree that the priority should be with AAA-AC work (even though that holds
little interest for me; Windows Active Directory anyone?) so that should be the
focus of any rechartering.  Including DTLS at this stage would be to take
resources from AAA-AC and so delay it. (Resources  is not something that isms WG
is rich in:-)

As and when DTLS is part of a charter, I think that it would be very wrong to
include TLS.  SSHTM has been the most troublesome part of the three I-Ds so far,
and all the factors that make it so are present in full measure in DTLSTM.

Recall that when Pasi pointed out that securityName alice with transportAddress
[email-masked]:request produced a Response with securityName bob, it took five
months and endless e-mails to resolve.  And that is only the most recent of
issues where what is in the documents is not what people assume the documents
mean, each of which takes ages to resolve.  We might finish DTLSTM in less than
the four years it has taken us to progress sshtm but I cannot see it being
straightforward.

TLSTM is different, in many ways, not so much with the security aspects but in
having sessions and in the SNMP considerations. Right now, I expect that it
would be easier to do than DTLSTM just because of those sessions but putting the
two together in one docuemnt would be ... madness (IMHO).

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 May 2009 14:40:41 +0200

On Wed, May 06, 2009 at 12:36:18PM +0200, tom.petch wrote:

> I agree that the priority should be with AAA-AC work (even though
> that holds little interest for me; Windows Active Directory anyone?)
> so that should be the focus of any rechartering.  Including DTLS at
> this stage would be to take resources from AAA-AC and so delay
> it. (Resources is not something that isms WG is rich in:-)

Yes, I am concerned about the lack of resources. On the other hand,
the RADIUS AAA work is very different from the [D]TLS transport work
and we have a non-overlapping set of document editors. How much work
is needed on the AAA document would for me be easier to judge if there
would actually be a draft I could look at.

> As and when DTLS is part of a charter, I think that it would be very
> wrong to include TLS.  SSHTM has been the most troublesome part of
> the three I-Ds so far, and all the factors that make it so are
> present in full measure in DTLSTM.  Recall that when Pasi pointed
> out that securityName alice with transportAddress
> [email-masked]:request produced a Response with securityName bob,
> it took five months and endless e-mails to resolve.  And that is
> only the most recent of issues where what is in the documents is not
> what people assume the documents mean, each of which takes ages to
> resolve.  We might finish DTLSTM in less than the four years it has
> taken us to progress sshtm but I cannot see it being
> straightforward.
>
> TLSTM is different, in many ways, not so much with the security
> aspects but in having sessions and in the SNMP considerations. Right
> now, I expect that it would be easier to do than DTLSTM just because
> of those sessions but putting the two together in one docuemnt would
> be ... madness (IMHO).

As far as I understand TLS and DTLS, both protocols are pretty similar
in the way they authenticate principals, so I am not sure I share your
concerns (speaking as a technical contributor). How we deal with
[D]TLS certificates and map them to securityNames will be rather
common between TLS and DTLS based transports.

The proposed charter text posted by Wes does not state whether this is
going to be one or two documents; perhaps the best thing is to wait
until there is a concrete proposal on the table and then take an
informed decision.

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 May 2009 06:36:24 -0700

>>>>> On Wed, 6 May 2009 14:40:41 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> The proposed charter text posted by Wes does not state whether this is
JS> going to be one or two documents; perhaps the best thing is to wait
JS> until there is a concrete proposal on the table and then take an
JS> informed decision.

I did envision one, since that's what most people wanted *if* it could
be done cleanly, which I think it can (though since I haven't done it
yet, I reserve the right to change my mind later).  I'll start
immediately working on it after the decision by the WG is made that I
should be working on it in the first place.

FYI, the current DTLS draft already has two sub-transports: UDP and
SCTP.  It was not that difficult to add SCTP to the wording.  In fact
SCTP is closer to real TLS from a usage point of view since it's stream
based [it also happens to be message based too].  The biggest difference
between the wording between the UDP and SCTP components was how
streaming affects things [in quick summary: without streaming you have
to manually figure out the session id for the incoming packet].

Thus, in summary, I don't expect the TLS work to be hard at all.  The
bigger issue will be the careful search and replace and making sure the
wording works everywhere.  I don't think technical aspects will be
difficult at all.