[Hipsec] Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm

[Pekka Nikander <[e-mail]>]

Yes, we seem to be in violent agreement, Charlie, and that agreement  
concurs with what I remember that our intention was.  IIRC, we never  
discussed this issue into this detail before.

Taking the opportunity, I'd like to apply here also the "be strict in  
what you send, liberal in what you expect" rule here, and slightly  
weaken the language in other respects, too.  However, this should be  
taken as another issue (part 1 below) and we can decide on it  
separately from the default rule (part 2 below).

Here is my suggestion for revised text, part 1:

    When sending, there MUST NOT be more than six
    (6) HIP Suite-IDs in one HIP transform parameter.
    When receiving, the receiver SHOULD NOT rely on the
    sender not sending more than six Suite-IDs.

OTOH, I am happy with the original strict text, too, if there is any  
reason for it.   Any sensible implementation would not rely on it on  
receiving, anyway.

I would remove the next statement:

    The limited number of transforms sets the maximum
    size of HIP_TRANSFORM parameter.

OTOH, I don't remember the details of why we imposed the strict  
length rule in the first place.  Anyone?

Finally, suggested revised text, part 2:

    As the default configuration, the HIP_TRANSFORM parameter
    MUST contain at least one of the mandatory Suite-IDs.
    There MAY be a configuration option that allows the
    administrator to override this default.

--Pekka

On Apr 10, 2006, at 23:38, Charlie Kaufman wrote:

> If what you say in your note is the intent (and I think that's a  
> great thing to require), then I think the text needs to be  
> clarified. The language I was objecting to was in section 5.2.7:
>
>    There MUST NOT be more than six (6) HIP Suite-IDs in one HIP
>    transform parameter.  The limited number of transforms sets the
>    maximum size of HIP_TRANSFORM parameter.  The HIP_TRANSFORM  
> parameter
>    MUST contain at least one of the mandatory Suite-IDs.
>
> This implies that the HIP_TRANSFORM item is mal-formed if it does  
> not propose one of the mandatory Suite-IDs, which is much stronger  
> than saying that they must be present "in the default configuration".
>
> So it sounds like you and I agree. Is there anyone else out there  
> who wants to advocate the (current) stronger statement?
>
>         --Charlie
>
> -----Original Message-----
> From: Pekka Nikander [mailto:[e-mail]]
> Sent: Sunday, April 09, 2006 9:39 PM
> To: Charlie Kaufman
> Cc: HIP; Petri Jokela; Andrew McGregor; Petri Jokela
> Subject: Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption  
> as a mandatory algorithm
>
> Charlie,
>
> The crux of this issue seems to be that (IIRC) we'd like to mandate/
> recommend that the default configuration is one of the following:
>
>   1. Offer HMAC-SHA1-AES128CBC as the last resort cipher suite, _or_
>   2. Offer HMAC-SHA1-NULL as the last resort cipher suite
>
> That is, by default, one of the above MUST be offered.
>
> Now, is there something that you see problematic with such a
> requirement?  Maybe that the text is not clear enough in saying that
> the they are just the mandatory defaults, defined in order to ensure
> interoperability?
>
> If not, then I think we just need to clarify the text.
>
> --Pekka
>
> On Apr 8, 2006, at 9:49, Charlie Kaufman wrote:
>
>> I apologize that my mailer can't auto-generate the >> indentations
>> and at the moment I lack the patience to do it myself.
>>
>> I agree with Pekka that it's important that there could be a legal
>> implementation that did not offer encryption, so if you're going to
>> go down this path some Null scheme has to be mandatory to implement.
>>
>> But I still object to picking those algorithms as mandatory to
>> offer. While it guarantees interoperability between any two
>> compliant implementations (which is good), it comes at a cost of
>> disallowing *configurations* that only want to support some
>> stronger hash or that don't want to accept NULL encryption. I don't
>> know whether an RFC can say anything about the mandatory *default*
>> configuration, but I believe that's what you're really trying to
>> get at.
>>
>>         --Charlie
>>
>> -----Original Message-----
>> From: Pekka Nikander [mailto:[e-mail]]
>> Sent: Friday, April 07, 2006 12:40 AM
>> To: HIP
>> Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman
>> Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a
>> mandatory algorithm
>>
>>>>>> There is mandatory support for ESP with HMAC-SHA1 and either
>>>>>> Null or AES128CBC encryption. This is mandatory not just in the
>>>>>> implementation but also in the configuration. (i.e., as written,
>>>>>> the spec says that one of those two suites must be offered in
>>>>>> every negotiation).
>>>>
>>>> The reason for this was that we would have something common
>>>> between all nodes.
>>>
>>> But Null should not be mandatory to offer.  AES128CBC would do as a
>>> mandatory-to-offer.
>>
>> I don't understand this comment.  Maybe the text is unclear (Section
>> 5.2.7 I think), but AFAICS it just requires that the responder
>> includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC.
>> Nothing prevents it from including both and perhaps others.
>>
>> If you implement HMAC-SHA1-AES128CBC, it is trivial to implement  
>> HMAC-
>> SHA1-NULL.
>>
>> What is wrong with this?  To me this approach seems to be fine with
>> me; not all connections require encryption.
>>
>> --Pekka
>>
>>
>
>


_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec