Subject: RE: [Isms] working group last call ondraft-ietf-isms-transport-security-model-03

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Mon, 23 Apr 2007 16:28:28 +0200

Sorry for being late.

Here are my comments:

- may want to state in the abstract that there is a MIB module
  in this document.

- I am not sure I understand points 1 and 2 of section 1.5.
  
- Section 2, the last sentence leaves me wondering how it is specified 
  for SNMPv1 and v2c. I would think that many people may want to 
  deploy SNMPv2c with SSH based Transport Security?

  Now I do see that in sect 2.3 you explain/state that the Transport
  Security Model cannot be used with SNMPv1 and SNMPv2c. 
  I wonder if this is what the operator/user community wants/accepts??

  The only reason I can see is, that SNMPv1/v2c do not pass a
securityModel
  during message processing. Is that a good enough reason why they could
  not be securely transported? They certainly can be transported. The
  only thing is that once it gets top SNMPv1/v2c Message Processing, 
  there is nothing that will detect that the msg was secured and so
  it assumes unsecured transport (which may have impact in Access
Control 
  of course). But would we there fore state that such messages cannot be
  transported over TSM ?

- My arithmetic is not so great, but sect 2.3, 2nd para:
    In the RFC3411 architecture, a Message Processing Model determines
    which Security Model should be called.  As of this writing, there
are
    three Message Processing Models and three other Security Models:
    SNMPv1, SNMPv2c, and the User-based Security Model.

  For me the three and three do not seem to be in sync with the items
  listed after the colon. Possibly the 3 listed models are just the
  3 (other) security models. I think that is what it is, but I got
  confused. Maybe you can make it less confusing. Maybe I am the only
  one who got confused.

- I see: 3.1.2.  msgSecurityParameters

    Since message security is provided by a "lower layer", and the
    securityName parameter is always determined by the Transport Model
    from the lower layer authentication method, the SNMP message does
not
    need to carry message security parameters within the
    msgSecurityParameters field.  The field msgSecurityParameters MUST
be
    set to a zero-length OCTET STRING.

  I guess what we want to say is:

    - on incoming messages, the msgSecurityParameters field MUST be
ignored
    - on outgoing messages, the msgSecurityParameters field MUST be set
      to a zero-length OCTET STRING.

  In other words: be liberal in what you accept and conservative in what
you send

  But I see that in sect 5.2 step 2) you seem not to want to be so
liberal.
  Do we really want to generate an error if someone has put some data
into
  the msgSecurityParameters?

- In sect 3.2.1, I am not sure that the 2nd para belongs here?
  Such connection related info would not be saved in the
securityStateReference,
  but rather in the tmStateReference, no?

- In sect 4.1 we are adding
          IN   transportDomain         -- (NEW) specified by application
          IN   transportAddress        -- (NEW) specified by application
  as new parameters in the generateRequestMsg ASI.
  Should we not do so in the draft-ietf-isms-tmsm-07.txt document as
well?

- In sect 4.1 we're also adding 
          IN   transportDomain         -- (NEW) specified by application
          IN   transportAddress        -- (NEW) specified by application
  to the generateResponseMsg ASI.
  Why do we do that? Why would that not have been cached in one way or
another?
  So as to be sure that response returns to where the request came from?

  In fact, sect 4.2, step one states that the transportDomain/Address
are
  to be extracted from the securityStateReference. So it seem we indeed
do
  not need these 2 new parameters for prepareResponseMsg.

- In sect 4.2, step 1
     1) If the messageProcessingModel is SNMPv3, then the
securityEngineID
     is set to the local snmpEngineID, to satisfy the SNMPv3 message
     processing defined in RFC 3412 section 7.2 13a).

  Why do we have to become SNMP version dependent here?
  It would be fine to give all SNMP versions we know up till now the
  same treatment, no? RFC3584 (top of page 28) does the same thing,
  so we can do so too if it is SNMPv1 or v2c.

- It also seems to me that step 2 and 1 (in sect 4.1) are in conflict,
in
  that step 2 (on a generateOutgoingRequestMsg) saves
transportAddress/Domain
  (and other info) in tmStateReference but step 1 (on a
generateResponseMsg)
  seems to want to extract it from a different cache, namely
securityStateReference?

- At the top of page 21, I wonder if
        *   snmpTargetParamsSecurityName    "sampleUser"
  Should be marked with an asterisk.
  The securityName is securityModel INDEPENDENT (I believe).
  It may be the case that the TransportSecurityModel uses identity
  function (as does USM) for translating it to a securityModel
  dependent userName, but that does not make this value 
  TransportSecurityModel specific/dependent, does it?

MIB review:

- for the Counter32s, do we not need to state if (and if so which)
  discontinuities can occur? It seems this was modeled after the USM-MIB
  and yep we forgot that in that MIB module too. That does not mean
  we need to make the same mistake now.

-    tsmInvalidCache OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of messages dropped because the
                    tmStateReference referred to an invalid cache.

  This sounds as a "debugging internals of an implementation" object to
me.
  Do we need this?
 
- I wonder if we need something like unknown userNames ??
  What if a notification originator as a SecurityName configured
(through
  SNMP maybe) that cannot be mapped to a proper identity inside the
  transport model? Do we not want to be able to see that in some
statistic?

Here are nits and typos:

- section 1.3

     the SNMP architecture, as defined in [RFC3411],and the architecture

  s/,and/, and/

- page 4:
     2.  How Transport Security Model Fits in the Architecture

  s/How/How the/ ??

I did spend several hours on this.
But I think I need a second pass of a few dedicated hours (at least)
in order to make sure I have checked and understood everything.
Modularity is nice.... but it means you need to check several documents
at the same time in order to get the complete picture.

Bert Wijnen  

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Saturday, March 10, 2007 12:14 AM
> To: [email-masked]
> Subject: [Isms] working group last call 
> ondraft-ietf-isms-transport-security-model-03
> 
> Dear all,
> 
> This is the working group last call on the
>     "Transport Security Model for SNMP"
> to be found at
> <http://www.ietf.org/internet-drafts/draft-ietf-isms-transport
> -security-model-03.txt>.
> 
> The authors and the chairs think that this document is mature 
> enough for last call.
> 
> Please do review the document and post your comments on this 
> list until March 25, 2007.  Of course it would be great to 
> get your comments already before our next meeting on March 22.
> 
> Please also post to the list if you have read the document 
> and are fine with it as it is.  It is very useful to know how 
> many people have read the document.
> 
> Thanks,
> 
>     Juergen Q.
> -- 
> Juergen Quittek        [email-masked]       Tel: +49 
> 6221 4342-115
> NEC Europe Limited,    Network Laboratories        Fax: +49 
> 6221 4342-155
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   
> http://www.netlab.nec.de
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL, 
> UK Registered in England 2832014
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 24 Apr 2007 21:49:05 -0400

Hi,

I made the requested changes. 

dbh

> From: tom.petch [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 2:19 PM
> To: Juergen Quittek; [email-masked]
> Subject: Re: [Isms] working group last 
> callondraft-ietf-isms-transport-security-model-03
> 
> I commented before that I do not find s.2 clear.  I also 
> think that this is a
> crucial section for the document as a whole, especially for 
> those who have not
> lived with these ideas for the past two years, as it provides 
> the framework into
> which the details will fit.  I believe it should be explicit, 
> as in the
> following,
> with ** marking changes, of sentences or word
> 
> 
>  " The Transport Security Model is designed to fit into the RFC3411
>    architecture as a Security Model in the Security Subsystem, and
to
>    utilize the services of a secure Transport Model.
> 
> **The secure Transport Model maintains a cache, referenced by 
> tmStateReference,
> which is used to pass information between the Transport 
> Security Model and the
> secure Transport Model, and vice versa.
> 
> **If the Transport Security Model is used with an insecure 
> Transport Model, then
> the cache is unlikely to be populated with security 
> parameters, which will cause
> the Transport Security Model to return an error (see section 5.2)
> 
> **If another Security Model (eg Community-based Security 
> Model) is used with a
> secure Transport Model, then the cache will be populated but 
> the other Security
> Model may be unaware of the cache and ignore its contents (eg 
> deriving the
> securityName from the Community name in the message instead 
> of deriving it from
> the cache).
> 
> **When the Transport Security Model is used with a secure 
> Transport Model, as
> is intended to be the case, then the information in the cache 
> is used by
> the Transport Security Model to translate between the 
> security model-independent
> securityName and any identity used by the secure transport; 
> and to record the
> tmSecurityLevel provided for the message by the transport (a 
> level of security
> which may exceed the securityLevel requested for the message by the
> application).
> 
>                    To
>    maintain the RFC3411 modularity, the Transport Model does not
know
>    which securityModel will be used for an incoming message; 
> the Message
>    Processing Model will determine the securityModel to be used, in
a
>    Message Processing Model dependent manner.  In an SNMPv3 message
>    [RFC3412], the Transport Security Model **s/should/can/ be 
> specified in the
>    message header using the object securityModel.
> **The use of the Transport Security Model with other message 
> types is outside
> the scope of this document."
> 
> 
> This is intended to be a rewording of what has been agreed 
> and not to introduce
> changes.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Juergen Quittek" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, March 10, 2007 12:13 AM
> -security-model-03
> .txt>.
enough
> > for last call.
> >
> > Please do review the document and post your comments on 
> this list until
> > March 25, 2007.  Of course it would be great to get your 
> comments already
> > before our next meeting on March 22.
> >
> and are fine
> > with it as it is.  It is very useful to know how many 
> people have read
> > the document.
> >
> > Thanks,
> >
> >     Juergen Q.
> > --
> > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
> > Registered in England 2832014
> >

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Apr 2007 02:33:27 -0400

Hi, 

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Monday, April 23, 2007 10:28 AM
> Subject: RE: [Isms] working group last 

done.
> - I am not sure I understand points 1 and 2 of section 1.5.

I don't remember where I copied the first bullet from. I removed it.

The second says the TSM should not depend on third party functionality
such as AAA, since it may not be available during times of network
stress, and it doesn't.

>   of course). But would we there fore state that such 

TSM is a security model. You don't transport anything over TSM.

If somebody wants to use SSH-TM to transport SNMPv1/v2c messages, they
can but they will not get TSM as the security model because SNMPv1/2c
messages use the Community-based security model(s), per RFC3584.
>   confused. Maybe you can make it less confusing. Maybe I am the
only

Changed it:

In the RFC3411 architecture, a Message Processing Model determines
which Security Model should be called. As of this writing, IANA has
registered four Message Processing Models (SNMPv1, SNMPv2c,
SNMPv2u/SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1,
SNMPv2c, and the User-based Security Model).

>   the msgSecurityParameters?

As protection against viruses, yes.

>   but rather in the tmStateReference, no?

The Command Responder provides the (opaque) securityStateReference
when it requests the response message be generated. The security model
extracts the security info from the securityStateReference and sets
the transport "session" to be used for a Response message. 

However, the security model does not know whether the transport
connection has been closed (only the transport model knows this), and
if the connection no longer exists when the message reaches the
transport model, then the Response message MAY be discarded.

>   Should we not do so in the draft-ietf-isms-tmsm-07.txt document as

I added text to that effect in TMSM.

>   not need these 2 new parameters for prepareResponseMsg.

The SNMPv3 WG made a deliberate decision to not require that the
response always be based on securityStateReference; an example of when
this might be useful is when the request can be made without
encryption, but the response should be encrypted. 

The decision of whether the response must be sent using the same
transport parameters is made by a combination of the application, the
message processing model and the security model. In general, the
security model has the last say.  SNMPv3 and USM require the values in
securityStateReference to be used for the response. 

The SNMPv3 WG designed the RFC3411 architecure to be modular and
extensible. Unless we believe we have perfect knowledge of what future
applications and MPMs and security models will be, we should not
change the **architecture** to require that response messages can only
be sent to the same transport session that sent the request. The MPMs
and SMs can handle this just fine.

The SNMPv3 WG made a decision that architecturally, the MPM and
Security Subsystem should not get the transport information. The
changes we are making to integrate SNMP with existing secure
transports, we need to pass the transport information to the MP
subsystem and Security subsystem. The generateRequest and
generateResponse ASIs are at the same "level" of interface, and I
think if we change one to make transport info available, then we
should probably change both, so we do not have to have this discussion
for every MPM and SM designed in the future.

>   so we can do so too if it is SNMPv1 or v2c.

And we can do it for SNMPv4 and SNMPv5 and SNMPv6 and SNMPv7 and ...

WHY? Because SNMPv3 and ONLY SNMPv3 has a dependency on USM processing
that it should NOT have if we had really made MPM and SM processing
modular. But for expediency, we allowed dependencies between USM and
SNMPv3, which are reflected in the ASIs. securityEngineID should have
been something totally hidden inside the USM security model, but we
blew it by not having perfect understanding of how future models would
differ from USM.

The ONLY reason we need to set securityEngineID is because SNMPv3 EOP
was written with USM requirements embedded in its processing, so the
SNMPv3 EOP requires it be passed in an ASI. No other MPM requires this
parameter; no security model other than USM actually requires
securityEngineID.

This memo describes the Transport Security Model, and we will NEVER be
able to process SNMPv1 or SNMPv2c messages as far as I can tell. You
would need a new message format, or at least a new message processing
model to pass SNMPv1/v2c-style messages into the Transport Security
Model, which would NOT be the Community-based security models
described in rfc 3584. So what rfc 3584 does is immaterial to this
security model.

Personally I hope we eliminate USM once and for all, so we can move
away from the USM dependencies in the architecture and can move on to
a cleaner architecture. I personally have no desire to keep requiring
securityEngineID be used for no good reason in every future version of
security models and SNMP message processing models.

And, if it escaped your notice, I am passionate about this ;-)

>   seems to want to extract it from a different cache, namely
Section 4.1 refers to outgoing messages. For an outgoing response
(step 1), there should be a existing securityStateReference. 

For an outgoing message other than a response (step 2), we want to put
the information provided by the application about where to send the
message into the tmStateReference cache so the transport model knows
where to send it.

securityStateReference is not created when a request goes out, it is
created when a request comes in (section 5.2, step 9).

>   TransportSecurityModel specific/dependent, does it?
Hmmm. I'm not sure either. I removed the asterisk.

>   we need to make the same mistake now.

I added text that says the value is not persistent across reboots.
Does that address your concern adequately? I am not sure there is
value of having this be persistent.

>   This sounds as a "debugging internals of an implementation" 

InvalidCache is incremented on an incoming message when security
information has not been provided by the transport model, indicating
that the transport is not a secure transport (or possibly an
implementation error, but that is incidental).

> - I wonder if we need something like unknown userNames ??

InvalidCache provides this for incoming messages (The transport model
has not told us what securityName to use.)

>   transport model? Do we not want to be able to see that in some

That would need to be a counter for the specific transport model. 
For SSH-TM, for example, the identity transform is used to do the
mapping, so the mappng should always be successful (the authentication
may not be though).
Other security models might use different mapping techniques.
> at the same time in order to get the complete picture.

Also when editing. sigh.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 25 Apr 2007 15:07:03 +0200

<tp>some comments inline on Bert's comments on the text; getting a bit lengthy
so probably worth splitting if the discussion gets extended </tp>

Tom Petch

----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Juergen Quittek" <[email-masked]>; <[email-masked]>
Sent: Monday, April 23, 2007 4:28 PM
Subject: RE: [Isms] working group last

Sorry for being late.

Here are my comments:

<tp>
No but they have come from RFC3414 so ...
</tp>

<tp>
I too found this confusing and did suggest some alternative working to cover all
bases
</tp>

<tp>
I agree, confusing; I read the 'other' as meaning 'in addition'
</tp>

<tp>
I would generate an error since it suggests a pronounced mismatch in
understanding between sender and receiver
</tp>

<tp>
I think not since this is MPM to SM ASI, RFC 3412/4 as opposed to RFC3411.
</tp>

<tp>
I think that this has got tangled up with sending the Response back over the
session that the Request came over; if that is a MUST, then the ASI does not
need the parameters; but if it is a SHOULD, I am less clear.
</tp>

- In sect 4.2, step 1

<tp> Section 5.2 I think</tp>
     1) If the messageProcessingModel is SNMPv3, then the
securityEngineID
     is set to the local snmpEngineID, to satisfy the SNMPv3 message
     processing defined in RFC 3412 section 7.2 13a).

<tp>
The way I see it both caches are needed.  tmStateReference passes (a pointer to)
transport details between the (newly defined) transport model and the security
model while securityStateReference (which is already defined) does the same
between SM and MPM for Confirmed class messages
</tp>

<tp>
I agree
</tp>
<snip>

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 26 Apr 2007 16:55:03 +0200

Inline

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 8:33 AM
> To: Wijnen, Bert (Bert); 'Juergen Quittek'; [email-masked]
OK

> The second says the TSM should not depend on third party 
> functionality such as AAA, since it may not be available 
> during times of network stress, and it doesn't.
> 
So, my understanding is that TSM is not dependent on AAA, but somewhere
in the whole ISMS solution we will be dependent on AAA for
authorization, no?

securityModel
Control
> TSM is a security model. You don't transport anything over TSM.
OK, sorry I got mixed up here.

> If somebody wants to use SSH-TM to transport SNMPv1/v2c 
> messages, they can but they will not get TSM as the security 
> model because SNMPv1/2c messages use the Community-based 
> security model(s), per RFC3584.

So that could be an easy update to RFC3584, I guess, and then 
we could let those messages be handled by the TSM, no?

In any event, such could be done, And so I think it would be better
to not speak about a specific SNMP version in the TSM.

> >     which Security Model should be called.  As of this writing,
there are
> In the RFC3411 architecture, a Message Processing Model 
> determines which Security Model should be called. As of this 
> writing, IANA has registered four Message Processing Models 
> (SNMPv1, SNMPv2c, SNMPv2u/SNMPv2*, and SNMPv3) and three 
> other Security Models (SNMPv1, SNMPv2c, and the User-based 
> Security Model).
> 
Thanks.

> >     from the lower layer authentication method, the SNMP message
does not
> >     msgSecurityParameters field.  The field msgSecurityParameters
MUST be
ignored
> >   In other words: be liberal in what you accept and conservative in 
> > what you send
> > 
liberal.
> >   Do we really want to generate an error if someone has put some
data into
> As protection against viruses, yes.

Mmmm.. not sure I agree. 
If I am the only one... pls ignore me (on this point).

securityStateReference,
> The Command Responder provides the (opaque) 
> securityStateReference when it requests the response message 
> be generated. The security model extracts the security info 
> from the securityStateReference and sets the transport 
> "session" to be used for a Response message. 
> 
> However, the security model does not know whether the 
> transport connection has been closed (only the transport 
> model knows this), and if the connection no longer exists 
> when the message reaches the transport model, then the 
> Response message MAY be discarded.
> 
Yeah... but why do we need to say that in TSM ??

> I added text to that effect in TMSM.
thanks

> >   to be extracted from the securityStateReference. So it seem we 
> > indeed do
> The SNMPv3 WG made a deliberate decision to not require that 
> the response always be based on securityStateReference; an 
> example of when this might be useful is when the request can 
> be made without encryption, but the response should be encrypted. 
> 
> The decision of whether the response must be sent using the 
> same transport parameters is made by a combination of the 
> application, the message processing model and the security 
> model. In general, the security model has the last say.  
> SNMPv3 and USM require the values in securityStateReference 
> to be used for the response. 
> 
> The SNMPv3 WG designed the RFC3411 architecure to be modular 
> and extensible. Unless we believe we have perfect knowledge 
> of what future applications and MPMs and security models will 
> be, we should not change the **architecture** to require that 
> response messages can only be sent to the same transport 
> session that sent the request. The MPMs and SMs can handle 
> this just fine.
> 
> The SNMPv3 WG made a decision that architecturally, the MPM 
> and Security Subsystem should not get the transport 
> information. The changes we are making to integrate SNMP with 
> existing secure transports, we need to pass the transport 
> information to the MP subsystem and Security subsystem. The 
> generateRequest and generateResponse ASIs are at the same 
> "level" of interface, and I think if we change one to make 
> transport info available, then we should probably change 
> both, so we do not have to have this discussion for every MPM 
> and SM designed in the future.
> 

You clearly are convinced that what you have is correct.
I am not so convinced, but don't have the arguments ready right now
to gointo a discussion. So unless someone else picks up on this
I may accept your reasoning (or choice).

> WHY? Because SNMPv3 and ONLY SNMPv3 has a dependency on USM 
> processing that it should NOT have if we had really made MPM 
> and SM processing modular. But for expediency, we allowed 
> dependencies between USM and SNMPv3, which are reflected in 
> the ASIs. securityEngineID should have been something totally 
> hidden inside the USM security model, but we blew it by not 
> having perfect understanding of how future models would 
> differ from USM.
> 
iirc, we blew it for other reasons. But that is OK, we don't need
to re-open that debate, that is water under the bridge.

> The ONLY reason we need to set securityEngineID is because 
> SNMPv3 EOP was written with USM requirements embedded in its 
> processing, so the
> SNMPv3 EOP requires it be passed in an ASI. No other MPM 
> requires this parameter; no security model other than USM 
> actually requires securityEngineID.
>
So is it not such then that the securityEngineID is irrelevant
in this case and so that it does not matter what we set it to?

The only place (I think) were we erred in SNMPv3 MP is in RFC3412
page 36/37, step 13:

   13) If the pduType is from the Confirmed Class, then:

       a) If the value of securityEngineID is not equal to the value of
          snmpEngineID, then the security state information is
          discarded, any cached information about this message is
          discarded, the incoming message is discarded without further
          processing, and a FAILURE result is returned.  SNMPv3 Message
          Processing is complete. 

We can fix it in 2 ways:
- Update rfc3412 to say that we only check this for USM security model
  I know we'd rather not touch 3412
- In non-USM securityModels, no matter what, just always set 
  securityEngineID to the local snmpEngineID. It won't hurt (I think).

> This memo describes the Transport Security Model, and we will 
> NEVER be able to process SNMPv1 or SNMPv2c messages as far as 
> I can tell. 

We have not really explored that very much have we?

> You would need a new message format, or at least 
> a new message processing model to pass SNMPv1/v2c-style 
> messages into the Transport Security Model, which would NOT 
> be the Community-based security models described in rfc 3584. 
> So what rfc 3584 does is immaterial to this security model.
> 
Could it not be as simple as seeing that we get a tmStateReference
on incoming messages and then we know we need to send them to TSM?
It would mean eitehr an update to 3584, or a new document that 
describes SNMPv1/v2c over secure transport, we could called it 
SSNMPv1 secure MP and SNMPv2c secure MP (SNMPv1SMP and SNMPv2cSMP)
which would call TSM.
Not sure I would really want to stimulate continued use of SNMPv1,
but v2c might make sense. ANd if opertros tells us they won't
migrate away from v1, then we might as well try to make it secure
if it is reasonably odable over a secure transport.

> Personally I hope we eliminate USM once and for all, so we 
> can move away from the USM dependencies in the architecture 
> and can move on to a cleaner architecture. I personally have 
> no desire to keep requiring securityEngineID be used for no 
> good reason in every future version of security models and 
> SNMP message processing models.
> 
If it is as simple as "set it to loacalEngineID", then what is
the problem? OK not 100% clean, but what in our whole Internet is
100% clean anymore?

> And, if it escaped your notice, I am passionate about this ;-)
yeah I did. It brings up memories of our fruitfull discussion
in newHampshire in 1996 (I believe it was 96). ;-) when we worried so
much about not disturbing your neigbours at 2 or 3 am.

> Section 4.1 refers to outgoing messages. For an outgoing 
> response (step 1), there should be a existing securityStateReference. 
> 
> For an outgoing message other than a response (step 2), we 
> want to put the information provided by the application about 
> where to send the message into the tmStateReference cache so 
> the transport model knows where to send it.
> 
> securityStateReference is not created when a request goes 
> out, it is created when a request comes in (section 5.2, step 9).
> 
OK, I will reread a few times.

> Hmmm. I'm not sure either. I removed the asterisk.
good.

> Does that address your concern adequately? I am not sure 
> there is value of having this be persistent.
> 
Nop, if you reboot, that is always a possible discontinuity . If that is
the only possibility for discontinuity (I think it is),
then we just need to say that.

> >   This sounds as a "debugging internals of an implementation" 
> > object to me. Do we need this?
> 
> InvalidCache is incremented on an incoming message when 
> security information has not been provided by the transport 
> model, indicating that the transport is not a secure 
> transport (or possibly an implementation error, but that is 
> incidental).
> 

I am still somehwat confused. But if this is all that is left,
we're good shape.

> InvalidCache provides this for incoming messages (The 
> transport model has not told us what securityName to use.)
> 

So invalidCache is overloaded with multiple meanings?
Does not sound good to me.

> For SSH-TM, for example, the identity transform is used to do 
> the mapping, so the mappng should always be successful (the 
> authentication may not be though).

OK

> > Modularity is nice.... but it means you need to check several 
> > documents at the same time in order to get the complete picture.
> 
> Also when editing. sigh.
> 
yep, that must be worse. Cause you have to dream up (or design/compose)
the text. I only have to check if I think it is correct or not.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Apr 2007 18:27:44 +0200

On Thu, Apr 26, 2007 at 04:55:03PM +0200, Wijnen, Bert (Bert) wrote:
 
> So, my understanding is that TSM is not dependent on AAA, but
> somewhere in the whole ISMS solution we will be dependent on AAA for
> authorization, no?

My understanding is that a secure transport model _may_ call a AAA
service for authentication (e.g. verification of a password) and a
secure transport model _may_ (at the same time) call a AAA service for
service authorization. The details may be transport model specific.
In essence, AAA says "go ahead" or "go way" when the secure session is
being established.

As discussed in Prague, we believe that any further authorization via
a AAA service (e.g. policy mapping in the form of securityName to
groupName mapping) or even the provisioning of access control rules by
a AAA server are outside of the current ISMS charter, but may be
considered as future work items once we have successfully completed
the work we are chartered to do.

/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: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 27 Apr 2007 09:39:17 +0200

I agree with that.
But that means that such a security model IS (will be) dependent on a
3rd party service.
And the comment I had is that the document seems to state that we SHOULD
NOT depend
on other networkk services (point 2 in sect 1.5).
SO I can live if we remove that requirement, but we shouldbe honest in
advertising.

Bert Wijnen  

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Thursday, April 26, 2007 6:28 PM
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: [Isms] working group 
> lastcallondraft-ietf-isms-transport-security-model-03
> 
> My understanding is that a secure transport model _may_ call 
> a AAA service for authentication (e.g. verification of a 
> password) and a secure transport model _may_ (at the same 
> time) call a AAA service for service authorization. The 
> details may be transport model specific.
> In essence, AAA says "go ahead" or "go way" when the secure 
> session is being established.
> 
> As discussed in Prague, we believe that any further 
> authorization via a AAA service (e.g. policy mapping in the 
> form of securityName to groupName mapping) or even the 
> provisioning of access control rules by a AAA server are 
> outside of the current ISMS charter, but may be considered as 
> future work items once we have successfully completed the 
> work we are chartered to do.
> 
> /js
> 
> --

---

From: "David Harrington" <[email-masked]>
Date: Fri, 27 Apr 2007 11:12:27 -0400

Hi,

Please note the conditional that starts that constraint:
  2.  In times of network stress, the security protocol and its
       underlying security mechanisms SHOULD NOT depend upon the ready
       availability of other network services (e.g., Network Time
       Protocol (NTP) or Authentication, Authorization, and Accounting
       (AAA) protocols).

If we write a model that depends on third party services, either that
model should have an explicit built-in failover strategy, or it should
warn that the system MAY fail during times of network stress,
preventing management access to the managed node.

I will make a note to add such a warning to the secshell draft.

I would like to have an explicit fallover to local passwords in the
secshell draft, so I'll make a note to myself. When we start to
discuss sechell issues, we should make sure that gets raised. 

If we want to try to standardize a local passwords authn model and
then have various transport models that use third party authn servers
failover consistently to that (or another model that can be specified
specified by the failing authn model), we can do that too. It will add
complexity, but also robustness.

dbh

> Sent: Friday, April 27, 2007 3:39 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isms] working 
> grouplastcallondraft-ietf-isms-transport-security-model-03
> 
> I agree with that.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 27 Apr 2007 22:00:57 -0400

Hi,

> to not speak about a specific SNMP version in the TSM.

Proposed text in section 2.3:
"Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or
SNMPv2 Message Processing Models **as defined in RFC3584** cannot use
the Transport Security Model.  (This does not mean an SNMPv1 or SNMPv2
message cannot use a secure transport model, only that the RFC3584 MPM
will not invoke this security model.)"

This leaves the path open to a 3584bis, but makes it clear that the
current rfc3584 will not use this security model.

I removed all reference to message-version-specific processing. Now
the only place message versions are mentioned is in co-existence and
the security considerations. 

> If I am the only one... pls ignore me (on this point).

I'll let the chairs determine consensus on this.

> > > - In sect 3.2.1, I am not sure that the 2nd para belongs here?
[...] 
> Yeah... but why do we need to say that in TSM ??

I removed the warning.

>   securityEngineID to the local snmpEngineID. It won't hurt (I
think).

I modified the EOP for THIS security model to always set it to the
local engineID. 

> Does not sound good to me.

It is not really overloading the meaning; how you interpret things is
different for this security model than for USM.

To know when a username is unknown, you need a list of the known
usernames. USM is preconfigured with a list of known usernames; TSM
does not have preconfigured usernames, so all usernames are unknown. 

For outgoing messages, the application provides a securityName (via
the ASI or securityStateReference), and TSM puts it into the
tmStateReference cache. I will note that we do not verify it is not
empty.

For incoming messages, if the transport model provided a securityName
in the cache, then the securityName is known; if not, then the
securityName is unknown.

The security subsystem is responsible for providing the securityName
for the rest of the system, and this security model sets securityName
based on the securityName value in the cache (5.2 step 4), so a
missing cache or a cache with no securityName value is invalid as far
as this security model is concerned, so it reports this problem in
InvalidCache. Note that we do not check that the value of securityName
is valid, only that the cache exists and has a securityName field.

dbh

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Sat, 28 Apr 2007 12:17:30 +0200

Inline

Bert Wijnen  

> Sent: Saturday, April 28, 2007 4:01 AM
> > > If somebody wants to use SSH-TM to transport SNMPv1/v2c messages, 
> > > they can but they will not get TSM as the security model because 
> > > SNMPv1/2c messages use the Community-based security model(s), per 
> > > RFC3584.
> > 
> > So that could be an easy update to RFC3584, I guess, and 
> then we could 
> > let those messages be handled by the TSM, no?
> > 
> > In any event, such could be done, And so I think it would 
> be better to 
> > not speak about a specific SNMP version in the TSM.
> 
> SNMPv2 Message Processing Models **as defined in RFC3584** 
> cannot use the Transport Security Model.  (This does not mean 
> an SNMPv1 or SNMPv2 message cannot use a secure transport 
> model, only that the RFC3584 MPM will not invoke this 
> security model.)"
> 
> This leaves the path open to a 3584bis, but makes it clear 
> that the current rfc3584 will not use this security model.
> 
I guess I can live with it.
But I would remove it completely.
We do not have to specify what sorts of other (external) things
can or cannot work with us. We have defined our ASI, and that 
should make it clear.

> I removed all reference to message-version-specific 
> processing. Now the only place message versions are mentioned 
> is in co-existence and the security considerations. 
> 
?? not needed in co-existence in my view.
But I will turn quiet if everyone else is OK with above text.

No firther response to thr eest below.
Bert
> > > connection has been closed (only the transport model knows this), 
> > > and if the connection no longer exists when the message 
> reaches the 
> I modified the EOP for THIS security model to always set it 
> to the local engineID. 
> 
> > > >  
> > > InvalidCache provides this for incoming messages (The transport 
> > > model has not told us what securityName to use.)
> > > 
> > 
> It is not really overloading the meaning; how you interpret 
> things is different for this security model than for USM.
> 
> To know when a username is unknown, you need a list of the 
> known usernames. USM is preconfigured with a list of known 
> usernames; TSM does not have preconfigured usernames, so all 
> usernames are unknown. 
> 
> For outgoing messages, the application provides a 
> securityName (via the ASI or securityStateReference), and TSM 
> puts it into the tmStateReference cache. I will note that we 
> do not verify it is not empty.
> 
> For incoming messages, if the transport model provided a 
> securityName in the cache, then the securityName is known; if 
> not, then the securityName is unknown.
> 
> The security subsystem is responsible for providing the 
> securityName for the rest of the system, and this security 
> model sets securityName based on the securityName value in 
> the cache (5.2 step 4), so a missing cache or a cache with no 
> securityName value is invalid as far as this security model 
> is concerned, so it reports this problem in InvalidCache. 
> Note that we do not check that the value of securityName is 
> valid, only that the cache exists and has a securityName field.
> 
> dbh
> 
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Sat, 28 Apr 2007 09:17:55 -0400

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

> Sent: Saturday, April 28, 2007 6:18 AM
> To: David Harrington; Juergen Quittek; [email-masked]
> messages, 
> > > > >   But I see that in sect 5.2 step 2) you seem not to 
> want to be
> > so
> > > liberal.
transport 
> > > > InvalidCache provides this for incoming messages (The
transport

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Apr 2007 12:26:33 +0200

> discuss sechell issues, we should make sure that gets raised. 

In practical PAM implementation terms, the failover strategy is
determined by the PAM configuration. Requiring a failover to local
passwords simply means that some legal PAM configurations may break
RFC compliance. So I would prefer that the applicability section
discusses this point and suggests failover to local passwords rather
than requiring it.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Apr 2007 12:43:42 +0200

On Fri, Apr 27, 2007 at 10:00:57PM -0400, David Harrington wrote:

BW> Do we really want to generate an error if someone has put some
BW> data into the msgSecurityParameters?

DH> As protection against viruses, yes.

BW> Mmmm.. not sure I agree. 
BW> If I am the only one... pls ignore me (on this point).
 
DH> I'll let the chairs determine consensus on this.

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?

The be liberal in what you accept rule would call for simply ignoring
the value (Bert Wijnen's position) while Dave Harrington is concerned
that implementations may do arbitrary non-sense with the data. Please
let me know your opinion.

/js

As a technical contributor, I would prefer to simply ignore
msgSecurityParameters (like I ignore other fields in SNMP messages
that are of no use, e.g., values in get class operations).

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 30 Apr 2007 11:01:10 -0700

Hi,

To allow failover to something other than local passwords
based on configured policy to be RFC-conformant, but still
maximize interoperability, how about adding a SHOULD (rather
than a MUST) for failover to local passwords (that explains
how it might be at variance with a legitimate local policy)?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Monday, April 30, 2007 5:27 AM
To: David Harrington
Cc: [email-masked]
Subject: Re: [Isms]
workinggrouplastcallondraft-ietf-isms-transport-security-model-03

/js

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007 9:14 AM

---

From: "tom.petch" <[email-masked]>
Date: Mon, 30 Apr 2007 17:53:18 +0200

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 30, 2007 12:43 PM
Subject: Re: [Isms] working group

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

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Apr 2007 21:36:06 +0200

> how it might be at variance with a legitimate local policy)?

Why should we standardize local policy? A fallback mechanism to local
passwords might even be a security nightmare if those local passwords
never get changed.

I am find to discuss fallback mechanisms and the pros and cons of them
but I somehow feel SHOULD or MUST language may go a bit to far.

/js