Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

[Kent Watsen <[e-mail]>]

Hi Benjamin,


>> Yes, that is the correct URL.  I've fixed it in my local copy.  
>> The 802.1AR spec is behind a paywall, but it says this about the serial number:
>> 
>>   An IDevID certificate subject field be non-null and should
>>   include a   unique device serial number encoded as the 
>>   serialNumber attribute(RFC 5280 X520SerialNumber).
>> 
>> From RFC 5280:
>> 
>>    X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))
>> 
>>    ub-serial-number INTEGER ::= 64
>> 
>>    The character string type PrintableString supports a very basic Latin
>>    character set: the lowercase letters 'a' through 'z', uppercase
>>    letters 'A' through 'Z', the digits '0' through '9', eleven special
>>    characters ' = ( ) + , - . / : ? and space.
>> 
>> Any comments/concerns about this?
>
> Sigh.  There could be some excitement here (but might not be), but I think
> I'm going to have to defer to some people with more DNS (and X.500)
> expertise.  There's several potential (but not certain) issues here,
> including at least:
>
> (1) ub-serial-number is 64, and the maximum length of a DNS label is 64
> octets, so we have no room for escaping or encoding at the margins.
>
> (2) RFC 1034 suggests that DNS domain name comparisons should be performed
> in a case-insensitive manner (for alphabetic ASCII a-z/A-Z), but that
> labels themselves can contain arbitrary octets.  There is some placation
> here in that X.520 appears to define the Serial Number attribute should use
> a caseIgnoreMatch equality matching rule, so maybe this is a non-issue.
>
> (3) Those extra characters (other than '-') are not allowed in DNS host
> names.  AIUI, that technically shouldn't be a problem for this usage, but
> I'm not 100% confident, and maybe some implementations are wrong.
>
> (4) Using '.' in a label is pretty rare and require escaping for textual
> presentation (but this is not inherently a fatal flaw and would not hit the
> 64-character limit on label length).
>
> But on the whole, the question I want to ask myself here is along the lines
> of "how likely is there to be implementation incompatibility in this
> space?".  If serial numbers in practice are not using the full flexibility,
> this could still be a non-issue.

Be aware that the draft must, in general, say something about the serial
number for each source of bootstrapping information (and note that the
draft leaves open the possibility that more "sources" may be defined in
the future):

  Removable Storage:
    - okay, well, the draft punts on providing an actual file-naming
      convention but, in theory, there could be a directory per 
      serial-number.  E.g., /<serial-number>/<artifact-file>.

  DNS:
    - TXT in <serial-number>._sztp.local.   (multicast)
    - TXT in <serial-number>._sztp.<domain>.  (unicast)

  DHCP:
    - the draft punts here as well. DHCP is the only source of
      bootstrapping information defined by the document that
      doesn't support device-specific response (bootp payloads
      are *way* too small!)

  SZTP Bootstrap Server:
    - device MUST identify/authenticate itself using its serial-number.
    - device SHOULD use a client-certificate (DevID RECOMMENDED)
    - device MAY use an HTTP authentication scheme but, if it does so,
      it MUST identify itself using its serial-number.

Lastly, for any source, if "signed data" is returned, the ownership
voucher [RFC 8366] defines a "serial-number" leaf that MUST be
populated with the serial number value.

In general, it is felt that, if a device vendor's serial-numbers
contain characters that are not supported by some protocol or format,
then that is their problem to solve.  That said, most protocol/formats
will define some escaping mechanism and, if not, the vendor can create
some mapping.

As for serial-number lengths exceeding some limit, then it may mean
that the device vendor either can't use that bootstrapping strategy,
or, again, they come up with a mapping of some sort (e.g., a hash).
But I doubt serial numbers ever get so long, as they are many times
typed or spoken, and users would revolt if they were too long ;)

My hope is that we can ignore this concern altogether, or maybe just
have a Security Considerations section that essentially captures the
above.  Thoughts?

Kent