Subject: [Isms] WGLC comments - draft-ietf-isms-transport-security-model-05.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 9 Aug 2007 13:56:23 +0200

1. Is RFC 2828 referred by other security-related documents? I find this
document problematic, there is a revision on the table IESG table that
has also problems and I decided that I cannot support it because among
other inadequate terminology concerning SNMP and management aspects. The
way it is mentioned in Section 1.2 may be interpreted that with the
right timing this document could be relevant, which is not the case IMO.
I would either ignore it, or just mention that the terminology in this
document is not intended to be consistent with RFC 2828. 

2. It would be good to include the comment that MIB objects defined here
SHOULD not be referenced in other documents in the MIB module itself,
maybe in the DESCRIPTION clause. 

3. Bert already mentioned the issue of

        ::= { snmpModules xxxx }

Actually I believe there is a justification of consistency with the
snmpUsmMIB which was defined prior to RFC 4181 if the authors believe
that this is important, but I agree that snmpTsmMIB is a better MIB. 

If you do take this path, I believe that you should clarify in the IANA
considerations section that the policy of further assignments of new
values under snmpModules is Standards Action.

4. Some abbreviations (MPM, ASI) are being reused from other SNMP
documents as RFC 3411 without being expanded at first occurrence or the
origin being referred to. 

Dan

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Aug 2007 10:00:08 -0400

Hi,

comments inline. 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Thursday, August 09, 2007 7:56 AM
> To: [email-masked]
> Subject: [Isms] WGLC comments 
> -draft-ietf-isms-transport-security-model-05.txt
> 
> 

The issue was raised during WGLC that there is a difference between
our use of the word authenticate and the glossary in RFC2828. I think
re-defining the English words will not help the IETF write clear and
unambiguous specifications.

If a document does use the RFC2828(bis) definitions, then that
document should clearly specify which words it uses are consistent
with the RFC2828(bis) terminology. 

I think it would be a bad idea to require or even claim consistency
with RFC2828(bis), because it will be tremendously hard to verify that
every word or phrase covered in RFC2828(bis) is used correctly in the
document. It is already hard to verify that MUST/SHOULD/MAY are used
correctly, and RFC2828bis has 300 pages of definitions.

I will word-smith this section.

> maybe in the DESCRIPTION clause. 

I'll look at how I can add that to the MIB definitions.

> values under snmpModules is Standards Action.

I can live with this either way. 

> origin being referred to. 

I'll check for this.

dbh

---

From: "tom.petch" <[email-masked]>
Date: Fri, 10 Aug 2007 08:40:42 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Romascanu, Dan (Dan)'" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 09, 2007 4:00 PM
Subject: RE: [Isms] WGLC
comments-draft-ietf-isms-transport-security-model-05.txt

Dan

I raised the issue earlier, that there are two distinct uses I see for
authentication, within the IETF and without, the USM use and the TLS./SSH use
(and it has been argued, on the TLS list and other, that what TLS provides is
not authentication).  I have no problem with the current SNMP RFC since RFC3414
makes it clear what you get; with isms using the same language, and with TLS/SSH
providing a quite different facility, I think that the elements could mislead
someone into thinking that they are getting a security that they are not..  I am
happy that the current text clarifies this; I like the definitions of
authenticity in RFC2828 - they are in accord with what I see elsewhere.  But the
current text goes beyond the issue I raised so hopefully there is scope in the
middle which will satisfy us both

Tom Petch

<snip>
.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Aug 2007 18:34:47 -0400

> unambiguous specifications.

Neither will misusing a term of art.  The reality is that _every_ technical 
field (and here I mean "technical" in the broadest sense) has its own 
jargon and "terms of art" which do not always have the same meaning they do 
in the mainstream.  In security, "authenticate" is one of these terms; the 
narrower scope described by RFC2828 is the meaning commonly used in the 
security community and it is SNMP that is unusual here.

That said, I agree that for these documents, consistency with other SNMP 
specifications is generally more important than consistency with terms used 
in the security community, where the two conflict.  However, where there is 
_not_ a conflict, consistency with security usage is preferable to taking a 
term which has well-established meaning in that community, using it in a 
security document in a way which is not consistent with that meaning, and 
asserting that it is OK not to call out the difference because your meaning 
is the "mainstream English" meaning.

> correctly, and RFC2828bis has 300 pages of definitions.

Certainly.  There is no such requirement, and I don't believe there is 
general interest within the IETF security community in introducing such a 
requirement.  RFC2828 and its successor attempt to document terms readers 
find, and to encourage writers to be consistent with common usage (where 
"common" means within the security community, not the world at large). 
However, it is not an internet standard, and while the recent document 
received extensive review and input from members of the security 
directorate, it reflects the decisions made by its author and _not_ a 
consensus of the IETF security area.

People who want to know more on the state of this might ask the Security 
Area Directors for more information or clarification.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Fri, 24 Aug 2007 18:16:00 +0200

<bottom post>
Tom Petch

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "David Harrington" <[email-masked]>; "'Romascanu, Dan (Dan)'"
<[email-masked]>; <[email-masked]>
Cc: "Jeffrey Hutzelman" <[email-masked]>
Sent: Thursday, August 23, 2007 12:34 AM
Subject: RE: [Isms]
WGLCcomments -draft-ietf-isms-transport-security-model-05.txt
> Area Directors for more information or clarification.

I raised the issue of the use of the term authentication in the isms I-D because
a security AD ticked me off for being sloppy in my use of the term, for failing
to distinguish between the two kinds.  This has, perhaps, made me picky over the
subject, hence my WGLC comment on the isms I-D, where I see the use of the term
as being not as precise as mine was.

I quoted RFC2828/RFC4949 in support of my case when perhaps I should have quoted
the security AD's e-mail that ticked me off.  I do fully (?) understand all the
different categories of RFC, the reviews that they have or have not been
subjected to and the status of FYI 36 compared to STD0062.  I had not
appreciated - until very recently - that there was resistance to FYI 36.

Whatever, I am content with the outcome.

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 24 Aug 2007 15:10:24 -0400

On Friday, August 24, 2007 06:16:00 PM +0200 "tom.petch" 
<[email-masked]> wrote:

>  I do fully (?)
> understand all the different categories of RFC, the reviews that they
> have or have not been subjected to and the status of FYI 36 compared to
> STD0062.

I never meant to imply otherwise.  I was just providing some background on 
this particular document, which could have represented a strong consensus 
of the security community and still be published in exactly the same way. 
But in fact, it was not undertaken as a group effort and while the author 
solicted and received lots of input, he didn't agree with every comment, 
did not ask for a consensus, and did not represent the document as 
reflecting such a consensus.  Which, BTW, I think is a fine thing -- 
actually achieving community consensus on such a large glossary would be 
quite difficult.

-- Jeff