Subject: Re: [Isms] wg last call on the (d)tls transport model

From: Wes Hardaker <[email-masked]>
Date: Tue, 08 Dec 2009 16:10:08 -0800

>>>>> On Sun, 1 Nov 2009 09:57:49 -0500, "Donati Andrew-MGIA0477" <[email-masked]> said:

DA> I read the (d)tls transport model document and here is the full
DA> summary of my comments: (The first 3 items were posted to the list
DA> previously)

Thanks for the comments and suggestions.  My responses are prefixed
below with "WH:" if you want to search for them.  The status of each
item is as follows:

  DONE:     Suggestion was acted on
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
  DISCUSS:  There is an outstanding question back to you

* DONE 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 useful to have
  tlstmSessionInvalidServerCertificates as an additional
  binding, especially if this object is the trigger.
  + WH: After WG discussion I did add these requested objects.  They've
    also been restructured a touch since the last time you read them to
    make them more clear (due to other comments).

* DONE Standard authentication failure notification. 
  There may have been some previous discussions about possibly using the
  standard authenticationFailure trap for tlstm (client) authentication
  failures.  Will this be used or mentioned in the document?
  + WH: I added a entry in the EoP to discuss when this should be
    sent during the establishing a session rules.
  
* DONE tlstmServerCertNotFound 
  Will it be feasible to have a scalar object that serves as a counter for
  this event? 
  If implemented, it can be added to this notification.
  + WH: The two notifications, as discussed above, were cleaned up and a
    counter was added.  Please see if the new text meets your needs.
          
* DONE Section 6.4 Configuration Tables 
  There is double verb, (is are), in the 2nd sentence.
  + WH: fixed, thanks!
  
* DONE Section 6.4.1 Notifications 
  This section mentions a notification (tlstmServerAuthFailure)
  that alerts management stations when the server's presented
  certificate does not meet the expected value but does not
  appear to have a statement that directly refers to the
  tlstmServerCertNotFound notification.
  + WH: Good point; I changed the text to this:
  
    The TLSTM-MIB defines notifications to alert management
    stations when a (D)TLS connection fails because a server's
    presented certificate did not meet an expected value
    (tlstmServerCertNotFound) or because cryptographic
    validation failed (tlstmServerAuthFailure).

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 08 Dec 2009 16:19:04 -0800

>>>>> On Fri, 6 Nov 2009 12:15:14 +0100, <[email-masked]> said:

PE> Some random comments scribbled on printout during my flight earlier
PE> today (or yesterday, depending on your point of view :-):

Pasi,

* DONE Technical 
  + DONE How the notification originator authenticates the other end (TLS 
    server) when fingerprints are not used is very unclear (the
    fingerprint case is clear). Section 5.3, step 3b, suggests we could
    use path validation, but it doesn't e.g. say what the "reference
    identity" (in draft-saintandre-tls-server-id-check terminology) would
    be. Perhaps the MIB should allow specifying that reference identity.
    (MIB, tlstmAddrTable, is relevant here.)
    
    + WH: This was discussed in a past WG meeting and it was
      determined that it was out of scope to establish X.509
      path validation management.  So that's left up to possible
      future work, possibly within the PKIX or other working
      group that wants to take on creating an X.509 TA MIB.  I
      will state this fact more clearly and make sure it's
      declared as implementation dependent.
    
    + WH: I've reworded the section to make it much clearer about
      exactly what must be done.  See if the new wording fixes
      your issues.
    
  + DONE (I guess this applies to command generators, too, to some degree 
    at least -- they also act as TLS clients, and have to authenticate
    the server somehow.)
    + WH: correct...  They're in the same boat.  If there is no
      fingerprint for outgoing connections it's expected they do
      path validation through another out-of-scope process.
      
  + DONE While TLS supports several different authentication 
    mechanism (X.509 certs, OpenPGP certs, pre-shared keys,
    Kerberos, SRP, ...), TLSTM supports only one of them (X.509
    certs). This should be mentioned in e.g. Section 1 and Section
    4.1.
    + WH: I've added sentences to both those locations stating that
      other authentication forms are outside the scope of this
      specification.
    
  + DONE Section 1.1, 2nd to last paragraph, and Section 3.1.3: 
    These parts should probably explicitly say that the concept
    of "session" here is totally unrelated to TLS sessions in
    RFC 5246 (which are TLS-internal optimization detail not
    visible to TLSTM). But the name "tlsSessionID" is very
    poorly chosen, since it's very different from the TLS
    SessionID in RFC 5246.
    + WH: How does tlsSnmpSessionID sound?  I've changed it to this.
    + WH: Note that I think it's possible to use the same sessionID
      for both uses.  It gets a bit more trick after
      renegotiation though since the SNMP session ID can't
      change.  I've added text describing this potential conflict.
    
  + DONE Section 5.3 (last para) and Section 8.2: (D)TLS does have the 
    "server_name" extension that does allow doing this.
    + WH: Added a reference to RFC4366.
      
  + DONE MIB, Snmp*Address TCs: do we need four pages worth of new TCs 
    to just describe (IPv4 address/IPv6 address/hostname)+port? 
    Surely many existing MIBs use address+port, too, and we could
    import from somewhere?
    + WH: per discussion at IETF, I've changed this so it's a single
      address TC now and the 3 Domains all use it.
    
  + DONE MIB, Fingerprint TC, last paragraph: this is not really 
    consistent with how certificate fingerprints are used in many
    other protocols -- usually we compare just the fingerprint
    (not the whole certificate), and assume it's produced by a
    good hash function.
    + WH: Per IETF discussion I've made it so that fingerprints can
      be used as the method of comparison.  (Originally the text
      was actually written to allow for "cheap" referencing
      methods (beyond just hash fingerprints)).
    
  + DONE MIB, tlstmCertToSNSANType: is SecurityName case sensitive?  If it 
    is, you need to specify the case for IPv6 address, and probably
    normalize the dNSName and domain part of rfc822name (e.g., convert to
    lower case).
    + WH: Modified per discussion results during the IETF meeting.
    
  + DONE MIB, tlstmCertToSNSANType: how would othername be converted to 
    SnmpAdminString? (which is UTF-8, so "take the raw DER" does not work,
    and it would be very administator-unfriendly, too)
    + WH: As per discussion from the IETF, we're no longer directly
      defining otherName mappings but do have an extensible OID
      selection mechanism so future documents can define an
      otherName mapping.
    
  + DONE Sections 3.3 and others: the document has snmpTLSDomain, 
    snmpDTLSUDPDomain and snmpDTLSSCTPDomain. Probably for consistency,
    the first should be snmpTLSTCPDomain, since SCTP would also normally
    use TLS, not DTLS (there's a draft proposing how to run DTLS over
    SCTP, but it's just work in progress, not something that can be done
    today).
    + WH: Ok, I've changed it.
    
  + DONE Section 2.1: if the CG/NO is always the (D)TLS client, and it MUST 
    be authenticated (2nd bullet), then why is authenticating the client
    only SHOULD? (1st bullet)
    + WH: Because I changed one from a SHOULD to a MUST and missed the
      second.  Thanks for the catch.  I also cleaned up the wording a
      bit more to make it clearer.
    
  + DONE The openSession ASI in Section 4.4.1 looks very different 
    from the SSHTM ASI -- is this intentional?
    + WH: The SSH document changed from the point where that text
      was copied and I didn't catch it.  I've realigned the
      document to the published RFC.
    
  + DONE Section 4.4.1: "this restriction is not needed for TLS or DTLS over 
    SCTP": this restriction is present in TLS-over-TCP/SCTP, too, but
    TCP/SCTP take care of ensuring that <src IP, src port, dst IP, dst port>
    is unique.
    + WH: That section was actually dropped as it was TLS specific
      ASIs and is no longer included with the document.
    
  + DONE Section 4.4.2 and 4.4.3: I think these sections should be 
    just deleted -- these are TLS internal details. Furthermore,
    for normal TLS (or DTLS, when a single datagram contains
    multiple DTLS records), TLSTM cannot even determine
    "wholeTlsMsgLength", since that would require parsing the TLS
    messages (which would be a layering violation).
    + WH: I agree and per discussion during the WG meeting, I've
      removed them.
    
  + DONE Section 5.1.1 is also a bit questionable; it also seems to 
    suggest parsing DTLS records by TLSTM. And the details aren't
    quite right: the same demultiplexing (mapping incoming UDP
    packet, based on <src IP,src port,dst IP, dst port> tuple, to
    the right DTLS connection/context) has to happen for DTLS
    handshake messages, too, not just DTLS application data
    messages.
    + WH: Per discussion at the IETF I've simplified it quite a bit
      so it still discusses demultiplexing within UDP but
      doesn't talk about (D)TLS specific packet types.  See if
      the new text looks better to you.
    
  + DONE Section 8.1, 1st paragraph: the last sentence of this 
    paragraph is very confusing, since the sessions this document
    talks about are totally unrelated to TLS sessions (and TLS
    session resumption).  Besides, all TLS implementations support
    session resumption, so this SHOULD is not really needed in
    this document.
    + WH: I've dropped the sentence
    
  + DONE Section 8.1, 2nd paragraph: Separate ports might be a 
    reasonable idea, but I don't understand what the rest of the
    paragraph is saying...
    + WH: It's discussing SNMP specific message types.  But I agree
      it's not needed.  Not only that, we're asking for separate
      ports from IANA anyway.  So...  I've deleted the whole
      paragraph as I don't think any of it is necessary.
    
  + DONE Section 10: SSHTM uses ports >1023 -- should be good enough 
    for TLSTM, too (the criteria for allocating ports <1023 is
    much stricter).
    + WH: I don't mind something higher and at the WG meeting
      everyone agreed.  Changed.
    
  + DONE In normal SNMP-over-UDP, if e.g. the notification receiver 
    restarts, that's not a problem: at least if the notification
    generator didn't send anything exactly when the restart was
    ongoing, everything will continue just fine after the restart.
    
    But when using DTLS-over-UDP, if the notification receiver
    restarts, the notification generator has to know that it needs
    to start a new DTLS "connection" (because otherwise the
    receiver will just silently drop all the packets it gets). The
    same problem has been discussed for syslog-over-DTLS recently,
    and draft-seggelmann-tls-dtls-heartbeat proposes one possible
    solution.
    
    In SNMP most requests result in a response, so if no response is seen,
    *some* component will know there's something wrong. But since TLSTM
    isn't supposed to know about PDU types, it might be architecturally
    slightly tricky how opening a new DTLS "connection" should be triggered
    here. But the document should probably say something about this issue.
    
    + WH: Per discussion in the WG meeting text was added to
      reference the heartbeat work and to recommend that users
      implement a dead-peer detection mechanism.
    
  + DONE Should the document say something about MTU/avoiding fragmentation 
    for DTLS-over-UDP?
    + WH: I added a paragraph in the operational considerations
      section that functionally says we can't summarize all
      those problems but readers should be aware of them.  I
      think if we dove down into it in depth it would amount to
      pages of discussions about the ramifications of each
      selection choice.
    
  + DONE DTLS allows multiple DTLS records in a single datagram -- should 
    the document say something about this?
    + WH: I've added some text describing this during the incoming
      processing EOPs.
    
  + DONE Should the document say something about SCTP Partial Reliability, 
    or use of SCTP streams?
    + WH: I think this falls into the text already added for
      "understand what's beneath you" in the operational
      considerations.
    
* DONE Minor editorial comments: 
  
  + DONE The document title should have the acronym "TLS" in it. 
    + WH: Added
    
  + DONE Section 4.1.1: While the actual details of how self-signed 
    certificates can be used in TLSTM (in the rest of the spec) look
    mostly OK, I would recommend against using the term "trust anchor" to
    refer to self-signed end-entity certificates.
    + WH: You're right it's another over-used term and is confusing
      depending on your definition of it (some use it as the
      keying material, but 5280 seems to declare it the entity
      producing the keying material)... How does this sound:
    
      "Trusted public keys from either CA certificates and/or
      self-signed certificates, must be installed through a
      trusted out of band mechanism into the server and its
      authenticity MUST be verified before access is granted."
    
  + DONE Section 3.1.1, item 4, 2nd paragraph: this is quite unclear, and goes 
    into details that are IMHO not relevant for TLSTM. Perhaps something
    like "Most TLS cipher suites do encryption" ?
    + I removed the offending text and shortened it so that it really
      says "(D)TLS" supports encryption.

  + DONE Section 3.1.1, item 5,: the sentence about "amplification" is quite 
    unclear; the main purpose of DTLS cookie exchange is to limit
    server-side resource consumption, not amplification (and "detecting"
    amplification could be tricky).
    + WH: You're absolutely right about this.  I'm surprised no one (myself
      included) has caught this before.  Thanks for pointing it
      out.  I've changed it to:
    
      "Implementations are not required to perform the stateless
      cookie exchange for every DTLS handshake, but in
      environments where an overload on server side resources is
      detectable it is RECOMMENDED that the cookie exchange is
      utilized."
    
  + DONE Section 3.1.2: This text should probably mention that TLS 
    does not have any NULL integrity cipher suites.
    + WH: I tried to clean this up a bit, but I'm not sure it should
      be our job to describe what TLS has and what it doesn't.
      (There is nothing prohibiting one from being created in the
      future, EG.)
    
  + DONE MIB, tlstmParamsEntry: should "usable" be "unusable"? 
    + WH: Yep; Juergen caught this too.
    
  + WONTDO Section 9, "DTLS is more vulnerable to denial of service attacks". 
    Well, a hypothetical version of DTLS that didn't include the cookie
    exchange might be more vulnerable, but since we don't have such
    a version, this isn't really true.
    + WH: I think the text following that statement functionally says
      just this so I don't think any changes are needed.  The
      paragraph is really there to remind users that they need to
      use cookies.
  + DONE Global: s/US-US-ASCII/US-ASCII/; 
    + WH: Whoops; that was a search-and-replace gone awry

  + DONE The reference [x509] looks wrong. 
    + WH: I think that was originally a reference to RSA which I
      removed long ago.  I've changed it to reference the ITU doc.
    
  + WONTDO Appendix A and B: I would suggest deleting these. 
    + WH: The WG decided that these contained useful information but
      should move to an appendix.
    
  + DONE Appendix C: "blueberry" is not a valid rfc822Name 
    ("[email-masked]" would be)
    + WH: changed

---

From: "David Harrington" <[email-masked]>
Date: Tue, 8 Dec 2009 20:49:23 -0500

Re: sessions

SNMP does not have sessions. RFC5590 says:

   The architecture defined in [RFC3411] and the Transport Subsystem
   defined in this document do not support SNMP sessions or include a
   session selector in the Abstract Service Interfaces.

   The Transport Subsystem might support transport sessions.  [...]

  However, because the handling of transport sessions is specific to
   each Transport Model, some Transport Models MAY restrict selecting
a
   particular transport session.  [...]

   Implementations SHOULD be able to maintain some reasonable number
of
   concurrent transport sessions, [...]

and from RFC5591:

   The Transport Security Model does not work with transport sessions
   directly.  Instead the transport-related state is associated with a
   unique combination of transportDomain, transportAddress,
   securityName, and securityLevel, and is referenced via the
   tmStateReference parameter.  How and if this is mapped to a
   particular transport or channel is the responsibility of the
   Transport Subsystem.

So any session ID here is specific to the TLS Transport Model
Ergo, I recommend tlstmSessionID.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Tuesday, December 08, 2009 7:19 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] wg last call on the (d)tls transport model
> 

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

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Mon, 21 Dec 2009 09:46:26 -0500

Wes,

Your efforts in evaluating and acting on these comments are greatly
appreciated.  One more thing that recently came to mind is possibly
adding a control specifically for tlstm notifications, which can be much
like the existing snmpEnableAuthenTraps object.

Andy Donati

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2009 7:10 PM
To: Donati Andrew-MGIA0477
Cc: Juergen Schoenwaelder; [email-masked]
Subject: Re: wg last call on the (d)tls transport model

  
  Will it be feasible to have a scalar object that serves as a counter
for

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Dec 2009 16:58:41 +0100

> like the existing snmpEnableAuthenTraps object.

I am wondering whether this is generally the right approach given the
fact that we have an access control model that can enable / disable
notifications.

/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: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Mon, 21 Dec 2009 11:33:03 -0500

Thanks. Since vacm access can already take care of this, we should be
all set the way it is.

- Andy Donati  

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, December 21, 2009 10:59 AM
To: Donati Andrew-MGIA0477
Cc: Wes Hardaker; [email-masked]
Subject: Re: wg last call on the (d)tls transport model

On Mon, Dec 21, 2009 at 03:46:26PM +0100, Donati Andrew-MGIA0477 wrote:
 
> adding a control specifically for tlstm notifications, which can be 
> much like the existing snmpEnableAuthenTraps object.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 21 Dec 2009 08:59:44 -0800

>>>>> On Mon, 21 Dec 2009 11:33:03 -0500, "Donati Andrew-MGIA0477" <[email-masked]> said:

DA> Thanks. Since vacm access can already take care of this, we should
DA> be all set the way it is.

Thanks.  (And thanks Juergen, because I was going to say the exact same
thing but you already had!)
-- 
Wes Hardaker
Cobham Analytic Solutions