Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm

["David Harrington" <[e-mail]>]

Hi,

>       This is a very important and well written document, and before
>       baloting a YES vote I would like to clarify a few issues:
> 
I agree this is a well-written document, except those portions copied
from my document ;-)

> 
> 3.1.2 DISCUSS 2) In Section 7: 
> -------------------------------
> 
>         Quoting the draft:
> 
>            snmpTlstmCertSANAny OBJECT-IDENTITY
>                STATUS        current
>                DESCRIPTION  "Maps any of the following fields 
> using the
>                              corresponding mapping algorithms:
> 
>                                Type         Algorithm               
>                               ------------+------------------------
>                                rfc822Name   
> snmpTlstmCertSANRFC822Name  
>                                dNSName      
> snmpTlstmCertSANDNSName     
>                                iPAddress    
> snmpTlstmCertSANIpAddress   
> 
>                              The first matching subjectAltName value
>                              found in the certificate of the 
> above types
>                              MUST be used when deriving the
>                              tmSecurityName."
>                ::= { snmpTlstmCertToTSNMIdentities 5 }
> 
>         Does the table prescribe the order in which various
>         subjectAltName types are checked?
> 
>         + WH: No, each "mapping algorithm" can prescribe it's own
>           method of searching in order to keep the table generic.
>           In fact, the table doesn't (by design) talk about
>           subjectAltNames themselves and that's left up to the
mapping
>           objects that define how to map certificate contents into
>           SNMPv3 securityNames.
> 
>         + Alexey: I might be missing something. This choice allows
>           different implementations to do different things. This
>           doesn't seem to encourage interoperability.
> 
>         + WH: I'm sorry if I've inadequately explained things.
>           Interoperability is definitely assured because all the
>           mapping algorithms we're defining in the document have
>           deterministic results.
> 
>           So, using this example taken straight from the appendix we
>           have the following mapping set up:
> 
>               snmpTlstmCertToTSNID          = 1
>                                               (chosen by 
> ordering preference)
>               snmpTlstmCertToTSNFingerprint = HASH 
> (appropriate fingerprint)
>               snmpTlstmCertToTSNMapType     = snmpTlstmCertSANAny
>               snmpTlstmCertToTSNData        = ""  (not used)
>               snmpTlstmCertToTSNStorageType = 3   (nonVolatile)
>               snmpTlstmCertToTSNRowStatus   = 4   (createAndGo)
> 
>           This says that if the incoming connection contains a
public
>           key in the verification tree that matches the HASH then it
>           should use the 'snmpTlstmCertSANAny' mapping algorithm
>           (which is assigned a unique OID within the MIB tree so it
>           can't be confused by another conflicting definition).
> 
>           So, looking up the rules for snmpTlstmCertSANAny we find:
> 
>               Maps any of the following fields using the
>               corresponding mapping algorithms:
> 
>                 Type         Algorithm                   
>                ------------+----------------------------
>                 rfc822Name   snmpTlstmCertSANRFC822Name  
>                 dNSName      snmpTlstmCertSANDNSName     
>                 iPAddress    snmpTlstmCertSANIpAddress   
> 
>               The first matching subjectAltName value found in the
>               certificate of the above types MUST be used when
>               deriving the tmSecurityName.
> 
>           The last paragraph clearly indicates we take the *first*
SAN
>           of the above types in order to do the mapping with.  So if
>           the certificate in use had 300 different SANs but the
first
>           was a rfc822Name containing [e-mail] then
>           that is the value that every implementation MUST pick in
>           order to meet the standard.  There is no ambiguity about
>           what happens if you follow all the rules for the
>           configuration specified in the MIB.
> 
>           The only extensibility is that future standards or
>           enterprises can define their own mapping algorithms,
>           assigned to their own unique OIDs that can be used in the
>           snmpTlstmCertToTSNMapType column.  We're actually
expecting
>           at some point in the future within the IETF to define a
>           standard for mapping (deterministically of course) the
>           kerberos principal from an otherName field.  (But since
that
>           doesn't exist now, it can't be used yet.)
> 
>           Make more sense?
> 
>         + David Harrington:
> 
>           I think the text you quote is not deterministic because it
>           says the tmSecurityName is derived, but doesn't specify
how
>           the derivation is done:
> 
>           >     The first matching subjectAltName value found in the
>           >     certificate of the above types MUST be used when
>           >     deriving the tmSecurityName.
> 
>           You do not specify a 1:1 identity mapping MUST be
>           used. Something derived is usually different than the
>           original. So if the subjectAltName was "David Harrington",
I
>           could derive a tmSecurityName of "David", "Harrington", or
>           "David Harrington H73653" and still meet the definition
you
>           quote. And if this was used in a securityName in a MIB
>           module, and read by a remote operator, it would not be
>           apparent that agent A's "David" was the same principal as
>           agent B's "Harrington".
> 
>           And I have to agree that if everybody gets to define their
>           own additional algorithms for derivation, even if they are
>           registered by OID, that doesn't lend itself to
>           interoperability. Is "IETF Review" required for every
>           algorithm so the algorithm is at least published publicly?
> 
>         + WH: Well, it does.  But if you missed it then more text is
>           needed to clarify it further.
> 
>           In particular:
> 
>               DESCRIPTION  "Maps any of the following fields using
the
>                             corresponding mapping algorithms:
> 
>                               Type         Algorithm          
>          
> 
>           Note that the mapping algorithm is specified in the second
>           column, and each of those mapping algorithms are
>           deterministic in nature (we worked hard to make sure that
>           all case-sensitivity, etc, was dealt with in the
>           sub-algorithms).
> 
>           If you're concerned about the above not being enforced
>           properly then I'll add the following new text (surrounded
be
>           ***s) to ensure compliance.
> 
>               DESCRIPTION  "Maps any of the following fields using
the
>                             corresponding mapping algorithms:
> 
>                               Type         Algorithm          
>          
>
------------+----------------------------
>                               rfc822Name   
> snmpTlstmCertSANRFC822Name  
>                               dNSName      
> snmpTlstmCertSANDNSName     
>                               iPAddress    
> snmpTlstmCertSANIpAddress   
> 
>                             The first matching subjectAltName 
> value found in the
>                             certificate of the above types 
> MUST be used when
>                             deriving the tmSecurityName.  
> ***The mapping algorithm
>                             specified in the 'Algorithm' 
> column MUST be used to
>                             derive the tmSecurityName.***"
> 
>           Does that appropriately address your concerns with respect
>           to the "determinsticness" of the mapping?
> 
>         + WH: Regarding everyone defining their own algorithms: this
>           is nothing new to the IETF or to SNMPv3.  We already allow
>           USM users, standards bodies and developers to define their
>           own security algorithms (i.e., auth and priv) via a
>           specified OID usable in the usmUserTable.  If you want an
>           IETF standardized algorithm, you likely need to publish it
>           via IETF process and get an assignment in the MIB tree
>           from IANA.  However, if you work at a device-vendor and
>           want to create your own then it's sort of up to you to get
>           it right.  E.G. Supposedly there is an OID that was
>           created to allow interoperable 3DES encryption between
>           certain SNMP stacks that supported that
>           enterprise-specific assigned encryption
>           identifier. Knowing the people that defined how it was
>           supposed to work, I'm sure they got it right and
>           interoperability problems haven't resulted. However, there
>           was nothing stopping them in the USM wording that required
>           IETF review for them to publish said OID.  Nor do I think
>           there should be.  We also allow enterprise-specific
>           security-model identifiers to be defined, but yet we don't
>           mandate IETF-review for them to start implementing or
>           publishing documentation about them.  How is this
>           different?
> 
>           The important aspect in my mind is that if two
>           implementations implement a mapping algorithm registered
>           at an OID and there are no flaws in the language that
>           define the OID then will interoperability succeed?  The
>           answer is certainly yes.  If the definition or the
>           implementation is flawed then interoperability will
>           certainly fail, just as it would for USM auth/priv
>           algorithms and SNMPv3 security model algorithms.
> 
>         + Alexey:
> 
>           Sorry, I've missed the text about ordering.
> 
>           However there is another more subtle problem with this
>           approach. My understanding is that many TLS APIs don't
>           necessarily allow to iterate through subjectAltName types
in
>           the order are specified in the certificate. It is more
>           common to have APIs that return SAN of a specific type. So
>           this choice really makes it hard for applications to
>           implement the mapping.
>           
>         + WH:
> 
>           I'm not sure about all the stacks.  If this is true I
>           suppose making the Any algorithm optional is the only way
to
>           recover.  We're implementing this using OpenSSL and it
seems
>           to return stuff in order, but I'll double check that
>           tomorrow.
> 
>           If other popular TLS X.509 manipulation stacks don't allow
>           for this we have the choice of:
> 
>           1) Deleting the snmpTlstmCertSANAny entirely.
>              (I don't favor this one at all)
> 
>           2) Making the snmpTlstmCertSANAny optional.
>              (My preference)
> 
>           3) Requiring everyone to implement it :-) 
> 
>         + Alexey:
> 
>           I generally feel you have too many choices for 
> extracting identity
>           from certificates. I think this is David's point as well.
>           And when you add algorithms that combine multiple 
> other choices in a
>           certain way, you increase the number of choices.
> 
>           But anyway, I think I need to think more about this 
> and we should
>           discuss this with the rest of IESG.
> 
>         + WH:
> 
>           It should be noted that the WG had this exact discussion
(in
>           Sweden) and the WG members were of the opinion that we
>           needed the "Any" option for ease of configuration.  I'm
>           reluctant to change the current behavior given these past
>           discussions.
> 
>           The output is deterministic so there is no issue with
>           interoperability unless the APIs can't handle it.
> 

I still have concerns about interoperability. I think we'll talk about
this during the telechat tomorrow.

 
> 3.2.1 CLOSED In Section 3.1.2, the last sentence of the last 
> paragraph: 
> --------------------------------------------------------------
> ----------
> 
>            Implementations SHOULD offer configuration settings for
>            mapping algorithms to SNMPv3 security levels.
> 

If we say it SHOULD, then shouldn't we provide the appropriate tables
in the MIB module?
I am not certain what such a mapping would look like.

> 
> 4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I 
> can't seem 
> --------------------------------------------------------------
> ---------
>         to find a definition of "transport domain"; is it a DNS
domain
>         name, a trust domain, or something else? (It seems to be
more
>         like an address type.) It might help to make this clearer in
>         the definitions of the snmpTLSTCPDomain and
snmpDTLSUDPDomain
>         transport domains.
> 
>           document you had read.  I'll put in a reference to RFC2579

Actually, 3417 is probably the preferred reference.


dbh