Subject: RE: [Isms] working group lastcallondraft-ietf-isms-transport-security-model-03

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 1 May 2007 09:18:51 -0700

The people I have been talking with and I conform to David's
observations (his 3 bullet points below). The general view (as seen from
my knothole) is wonder that any protocol could exist in our current
brave new world that cannot be adequately secured.

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Saturday, April 28, 2007 6:18 AM
To: 'Wijnen, Bert (Bert)'; 'Juergen Quittek'; [email-masked]
Subject: RE: [Isms] working group
lastcallondraft-ietf-isms-transport-security-model-03

Hi,

My own experience, and previous discussions on this mailing list, make
it quite obvious that
1) people would **like** to see TSM work with SNMPv1 and SNMPv2c, and
2) people **expect** that TSM will just work with SNMPv1 and SNMPv2c,
and
3) people are **surprised** to learn that, because of RFC3584, it does
not.

I think I have a pretty good understanding of the RFC3411 architecture
and the way RFC3412 dispatching works, but I was surprised TSM would not
work with SNMPv1 and SNMPv2c.

Even if the ISMS WG takes on the task of rewriting RFC3584,  3) would
not go away if the implementation used is not upgraded to RFC3584bis.
I think it reasonable to keep the explanation in the Co-existence
section of TSM, so people understand why 2) doesn't just happen.

dbh

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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 2 May 2007 14:21:28 +0200

I agree that taking the spirit of RFC3584 as is, there is no way to invoke TSM
from a v2c MPM.

But I see no bar to transporting v2c messages over a Secure Transport Model such
as SSH.  The application specifies SSH in transportDomain/Address along with
pduVersion 1 and securityModel 2.  The MPM generates destTransportDomain/Address
but I see nothing in the MPM to cause that to be any different to that which the
application requested.  No tmStateReference is generated.  The STM sees the SSH
transportDomain and uses or creates a secure tunnel over which to transport the
message.

On receipt, a tmStateReference is generated but ignored by the v2c SM which uses
securityParameters, if present, to generate a securityName via the
snmpCommunityTable

You gain privacy and integrity for the messages, and some degree of
authentication of the remote host.

Tom Petch

----- Original Message -----
From: "Fleischman, Eric" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, May 01, 2007 6:18 PM
Subject: RE: [Isms] working
grouplastcallondraft-ietf-isms-transport-security-model-03

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Saturday, April 28, 2007 6:18 AM
To: 'Wijnen, Bert (Bert)'; 'Juergen Quittek'; [email-masked]
Subject: RE: [Isms] working group

Hi,

dbh

---

From: "David Harrington" <[email-masked]>
Date: Tue, 8 May 2007 13:45:13 -0400

Hi,

I fully agree. I do not think we said in the subsystem document, and I
believe we will not say aything in the SSH Transport Model document to
the effect that one cannot use an SSH transport model with SNMPv1 or
SNMPv2c messages. 

All we have said is you cannot use the Transport Security Model in
combination with the RFC3584 message processing models, because the
RFC3584 processing will never route the message to the TSM. 

dbh

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, May 02, 2007 8:21 AM
> To: Fleischman, Eric; [email-masked]
> Subject: STM and v2CRe: [Isms] 
> workinggrouplastcallondraft-ietf-isms-transport-security-model-03
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 May 2007 14:41:22 -0400

On Monday, April 30, 2007 05:53:18 PM +0200 "tom.petch" 
<[email-masked]> wrote:

>> Since it is difficult to determine concensus with just two opinions, I
>> like to ask people to comment on this. The question is:
>>
>>    Shall a parser simply ignore the content of msgSecurityParameters
>>    or shall it raise an error?
>>
> Raise an error.  As I said before, I think it shows significant mismatch
> between sender and receiver and so should have attention drawn to it.
> This is security we are talking about.

"This is security" is a good argument for careful, reasoned design.
It is not an excuse for using knee-jerk paranoia instead.

Security design does sometimes require that "unused" fields be set to fixed 
or predictable values.  For example, if two parties will construct and hash 
a message independently, and then compare the hashes, there must be a 
canonical encoding.  The same applies if some party will decompose and 
reconstruct a message without being able to recompute the hash.  But I 
don't think either of those is relevant here.

It is true that "unused" fields whose contents are ignored can provide 
opportunities for hash collision attacks.  But there is a flip side, which 
is that such fields can also provide an opportunity to defend against such 
attacks and/or against cryptanalysis by inserting random confounders.  This 
approach has been used to strengthen X.509 certificates against potential 
hash collision attacks by issuing certificates with random serial numbers. 
But again, I don't see much relevance to the current question.

The golden rule is a good one, even in security protocol design.  Yes, of 
course one must require that security messages be well-formed and that all 
of the crypto checks out.  However, being too strict about the contents of 
fields that are only sometimes used can damage extensibility, making it 
much harder to replace a weak security protocol with a newer, stronger one 
in a way that can actually be deployed.

It strikes me that the language in the -03 draft was good -- it required 
that msgSecurityParameters be set to a 0-length octet string.  That's a 
requirement on the sender, not the recipient; no requirement was stated 
that the message be rejected if msgSecurityParameters is non-empty.  I 
believe this is the right approach, as it allows for extensibility if we 
discover that there actually is a reason we want to convey some parameter 
to the TSM.

I noticed that what was section 3.1 apparently disappeared entirely in -04. 
What's up with that?

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Fri, 18 May 2007 15:48:03 -0400

Hi,

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Friday, May 18, 2007 2:41 PM
> To: tom.petch; [email-masked]; David Harrington
> Cc: [email-masked]; Jeffrey Hutzelman
> Subject: Re: [Isms] working group 

As Bert pointed out, the security model really should be independent
of  the message processing model. Section 3.1 in -03- talked about the
fields in an SNMPv3-specific message format. 

As stated in the first paragraph of 3.1.1, "To maintain the separation
between subsystems, the Transport Security Model does not modify
Message Model dependent fields."

3.1.1 "msgFlags" says, in a roundabout way, the TSM compares the
securityLevel passed in the ASI to the securityLevel passed in the
tmStateReference. It does nothing to the msgFlags field. -04- has text
that says this more clearly in section 4.2.

3.1.2 msgSecurityParameters is set to a zero-length OCTET STRING; This
is now done in the elements of procedure in 4.3, in a wording that is
less message-version-specific.

dbh

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 May 2007 16:02:27 -0400

> less message-version-specific.

OK; that looks good.  However, I don't think we've resolved the question of 
whether the test described in 5.2 (2) is appropriate or necessary.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Fri, 18 May 2007 16:49:31 -0400

> discover that there actually is a reason we want to convey 

The Transport Security Model is not being designed to respond to
transport-model-specific parameters, only to
transport-model-independent parameters. If we decide there is a
specific reason to pass something to the TSM in the
msgSecurityParameters, then TSM would need to be updated when that
need is realized. Without such an update, TSM will not respond to data
in that field. 

Please give a real example of what we might want to pass to the TSM in
this field that would be transport-model and message-version
independent. We already have a strategy for extensibility; if the data
in the field is security mechanism specific, and we would have to
update TSM to recognize it, why would that not simply be a different
security model, one that did accept **specific** data in that field? 

How large a buffer should a receiver plan on for the undefined data
that might be sent in that OCTET STRING? Should we specify that all
recievers MUST be prepared to accept data of the largest possible
OCTET STRING size in this field for interoperability reasons? That way
all implementations can pay for the possibility that someday, somebody
might find a use for putting data in this field that would not be
transport-, message- or security-model specific. 

Call me skeptical.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 May 2007 17:31:13 -0400

> need is realized. Without such an update, TSM will not respond to data

True...  Except that with the EOP as currently written, it _will_ respond 
by rejecting the message.  I suppose that might be desirable, from an 
extensibility standpoint, except that it's not clear to me that "reject the 
message" means sending an error, as opposed to simply dropping it on the 
floor.

> independent.

I haven't a clue.  But then, extensibility is about planning for the 
ability to add things you haven't already thought of.

> We already have a strategy for extensibility; if the data

I suppose one could do that.  How does the negotiation work, where I don't 
know whether the recipient supports a particulaar security model?  So far, 
I don't think that's ever been an issue - the only security model was USM, 
and everyone supported that.  With ISMS, we can more or less assume that 
everyone still supports USM, and that anything that accepts an SSH 
connection from us will support TSM, too (assuming we're talking SNMPv3). 
What happens when a sender using SSH has a choice of TSM or some new thing; 
how does it tell whether the recipient supports the new thing?

> transport-, message- or security-model specific.

Who needs a buffer?  If you don't need it, just discard it.  But I very 
much suspect that by the time the TSM gets to decide to reject the message 
based on this field being non-empty, some other, security-model-independent 
component has actually parsed the message and had the opportunity to say 
the field is too long.

I guess I don't feel too strongly about this, but why require implementors 
to do this extra work to check that a field they don't care about is empty, 
when nothing is gained from doing so?

-- Jeff

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 18 May 2007 15:25:03 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Jeffrey Hutzelman'" <[email-masked]>; "'tom.petch'" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, May 18, 2007 1:49 PM
> Subject: RE: [Isms] workinggroup lastcallondraft-ietf-isms-transport-security-model-03
...
> transport-, message- or security-model specific. 

Any robust implementation has to be able to cope with the possibility that
unexpectedly large elements (and not just OCTET STRINGs) might
show up on the wire.  Anywhere.  I agree that zero-length should be
specified for the sender.  I'm agnostic on whether the recipient should care,
but inclined to favor the "ignore it" camp.

Randy