Re: [Hipsec] Host ID Parameter in RFC5201-bis

[Tobias Heer <[e-mail]>]

Hello Henrik,

I implemented your comments in RFC5201-bis. Do you think your comments are addressed adequately?

The new text on the HI looks like this:

5.2.8.  HOST_ID

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          HI Length            |DI-type|      DI Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Algorithm             |         Host Identity         /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                               |         Domain Identifier     /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type              705
     Length            length in octets, excluding Type, Length, and
                       Padding
     HI Length         length of the Host Identity in octets
     DI-type           type of the following Domain Identifier field
     Algorithm         index to the employed algorithm
     DI Length         length of the FQDN or NAI in octets
     Host Identity     actual Host Identity
     Domain Identifier the identifier of the sender

   The Host Identity is derived from the DNSKEY format for RSA and DSA.
   For these, the Public Key field of the RDATA part from RFC 4034
   [RFC4034] is used.  For ECC we distinguish two different profiles:
   ECDSA and ECDSA_LOW.  ECC contains curves approved by NIST and
   defined in RFC 4754 [RFC4754].  ECDSA_LOW is defined for devices with
   low computational capabilities and uses shorter curves from SECG
   [SECG].

        Algorithm
        profiles         Values

        RESERVED         0
        DSA              3 [RFC2536] (RECOMMENDED)
        RSA              5 [RFC3110] (REQUIRED)
        ECDSA            7 [RFC4754] (RECOMMENDED)
        ECDSA_LOW        9 [SECG]    (RECOMMENDED)

   For ECDSA and ECDSA_LOW Host Identities is represented by the
   following fields:


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          ECC Curve            |                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                         Public Key                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ECC Curve     Curve label
     Public Key    Represented in Octet-string format
                   [I-D.mcgrew-fundamental-ecc]

   For hosts that implement ECDSA as algorithm the following ECC curves
   are required:

        Algorithm    Curve            Values

        ECDSA        RESERVED         0

        ECDSA        NIST-P-256   1 [RFC4754]
        ECDSA        NIST-P-384   2 [RFC4754]

   For hosts that implement the ECC_LOW algorithm profile, the following
   curve is required:

        Algorithm    Curve            Values

        ECDSA_LOW    RESERVED         0

        ECDSA_LOW    SECP160R1        1 [SECG]

   The following DI-types have been defined:

         Type                    Value
         none included           0
         FQDN                    1
         NAI                     2


         FQDN            Fully Qualified Domain Name, in binary format.
         NAI             Network Access Identifier

   The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1.
   The format for NAI is defined in [RFC4282]

   If there is no Domain Identifier, i.e., the DI-type field is zero,
   the DI Length field is set to zero as well.



Best regards,

Tobias


Am 02.12.2010 um 17:14 schrieb Tobias Heer:

> Hello Henrik, 
> 
> thanks for the input. Short version: I think you comments are good and the HI parameter should be self-contained. I agree with removing the DNSKEY format.
> 
> More comments in line.
> 
> Am 30.11.2010 um 19:01 schrieb Henrik Ziegeldorf:
> 
>> Hi,
>> 
>> I'm currently implementing basic elliptic curve cryptography for HIP according to RFC5201-bis,
>> and have some suggestions concerning the Host ID parameter (Sect. 5.2.8).
>> 
>> I'd like to discuss the following points:
>> 
>> 1) Self-containment of the host_id parameter: For RSA/DSA identities an algorithm field is specified, for ECDSA identities there is none.
>> 
>> For RSA and DSA the format of the host identity field is defined as the DNSKEY format.
>> 
>>   0                   1                   2                   3
>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |             flags             |    protocol   |   algorithm   |
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |                                                               /
>>   /                          public key                           /
>>   /                                                               /
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
>> 
>> For ECC, the host identity field format is defined as follows:
>> 
>>   0                   1                   2                   3
>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |          ECC Curve            |                               |
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |                         Public Key                            /
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> Note, that the format for ECDSA identities has no algorithm field, which would allow to identify the use of ECDSA algorithm.
>> This isn't really serious, since we can determine from HIT_SUITE_LIST parameter which algorithms we use.
>> However, this leads to the parameter not being self-contained anymore,
>> since from the host_id parameter alone we cannot distinguish the algorithms in use, i.e. RSA, DSA or ECDSA.
>> 
>> I see two alternatives to provide for self-containment (and make it easier to implement):
>> 
>> 
>> a) Adapt the format of the ECC HI field to the format for RSA and DSA identities.
>>   I guess this would make sense, if their is some future usecase in HIP for the flags and protocol fields.
>> 
>>   0                   1                   2                   3
>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |             flags             |    protocol   |   algorithm   |
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |          ECC Curve            |          Public Key           /               
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
>>   /                                                               /
>>   /                                                               /
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
> After some thinking, I would not favor this alternative although there are efforts to define DNSKEY for ECC. First, I don't know if it is a good plan to attach to these ongoing efforts because they have different goals than HIP (e.g., http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04 only defines p-256 and p-384, no lower - we would not have a curve for low-power devices). We could try to ask for lower curves but I think it is not likely to have DNSKEY documents for all curves (e.g., binary curves, etc.) that might be needed for different HIP use cases.
> 
> If we wouldn't attach to these efforts and define our own curves but reuse the DNSKEY format and description we would need our own algorithm numbers assigned to be compatible with DNSKEY. I don't think this is useful in terms of standardization of DNSKEY. Hence, I would prefer the alternative mentioned below and define DNSKEY mappings for HIs instead. That way, one could still pull the keys from DNS and apply minor conversions to generate a HI from it.
> 
>> 
>> b) Dump the flags and protocol fields (and loose compatibility to DNSKEY Format as defined in RFC2535 3.1)
>>   and include algorithm as a fixed field in the host_id parameter, f.e.
>> 
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |             Type              |             Length            |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |          HI Length            |DI-type|      DI Length        |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |   Algorithm   |            Host Identity                      /
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     /                               |         Domain Identifier     /
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     /                                               |    Padding    |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> To me, this makes more sense, since values for the algorithms are already defined in Sect. 5.2.8
>> (but might only be used with the RSA, DSA formats).
>> 
>>        Algorithms       Values
>> 
>>        RESERVED         0
>>        DSA              3 [RFC2536] (RECOMMENDED)
>>        RSA              5 [RFC3110] (REQUIRED)
>>        ECDSA            7 [fundamental-ecc] (RECOMMENDED)
>> 
>> Without an explicit algorithm field, it is unclear where to use the ECDSA value.
> 
> To me it makes sense. Anyone on the list with good reasons not to do this?
> 
>> 
>> 2) If the host_id parameter format was not changed, the following happens:
>> 
>>  - First, we would need HIP_SUITE_LIST to distinguish RSA/DSA and ECDSA.
>>  - Then, in the RSA/DSA case we would need to peek into the host identity's algorithm field to distinguish RSA and DSA,
>>    since HIT_SUITE_LIST does not distinguish between RSA and DSA.
>> 
>>  I think it is nicer and cleaner to have one single field to distinguish between the RSA, DSA and ECDSA (and other future algorithms),
>>  instead of having this two-step process to distinguishing algorithms. (And also, this supports my point above.)
> 
> Yes, self-containment is essential - also for storing and passing on the HIs.
>> 
>> 
>> 2) Minor editorial change:
>>   In RFC5201-bis the definition of the ECC host identity gives the impression,
>>   that there seem are 2 undefined bytes directly after ECC Curve field.
>>   Shouldn't the format for ECC HI's be written like this instead:
>> 
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |          ECC Curve            |      Public Key               /
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
>>     /                                                               /
>>     /                                                               /
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
> ACK.
> 
> Tobias
> -- 
> Dipl.-Inform. Tobias Heer, Ph.D. Student
> Chair of Communication and Distributed Systems - comsys
> RWTH Aachen University, Germany
> tel: [phone]
> web: http://ds.cs.rwth-aachen.de/members/heer
> blog: http://dtobi.wordpress.com/
> card: http://card.ly/dtobi
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi