Subject: [Hipsec] NULL encryption mode in RFC 5202-bis

From: Tom Henderson <[email-masked]>
Date: Mon, 07 Jul 2014 21:54:34 -0700

Hi all,

Apologies for cross-posting, but Stephen Farrell raised a DISCUSS 
(seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: 
   Using the Encapsulating Security Payload (ESP) Transport Format with 
the Host Identity Protocol (HIP).  Stephen asked me to raise this 
question for discussion on both the HIP and SAAG lists.

Stephen's discuss questions the specification of "MUST to implement" for 
the NULL encryption option of the ESP_TRANSFORM parameter:

http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2

Stephen asks why is this a MUST to implement?  The history behind this 
that I'm aware of is that since HIP does not have an AH, only ESP, the 
ESP with NULL encryption mode can provide authentication.  It was also 
stated in previous drafts that this mode supports debugging.

Null encryption was also specified as a MUST to implement in RFC5202 and 
dates back to earlier versions of the HIP base draft (to 2003: 
http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).

- Tom

---

From: Miika Komu <[email-masked]>
Date: Tue, 08 Jul 2014 13:04:37 +0300

Hi,

> http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).

maybe we should keep it as it is for easier, incremental 
interoperability testing. The same issue was discussed earlier in this 
thread:

http://www.ietf.org/mail-archive/web/hipsec/current/msg01779.html

If you think this is a big problem, I'd suggest replacing NULL with 
suite id 9.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2014 11:33:02 +0100

Thanks Tom,

> http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).

Right. I guess my discuss has a generic part and a hip specific
part.

Generic: is it still considered a good plan to have null
confidentiality suites such as these? Or for those to be
Mandatory-To-Implement (MTI)? That clearly was the generic
consensus as we have these in a number of protocols. The
new reasons to move from that I think are: 1) we no longer
need this for debugging purposes really since libraries
and dev tools have moved on and are better now, and we
specifically no longer need these for protocols that are
no longer new, 2) BCP188 could be considered to argue
against having these as they could be misused. (All the
old arguments of course do still apply, but I think the
above are the ones that are new.) So is that enough to
shift the consensus away from having these or having
them be MTI?

Specific: is there anything specific about hip that would
trump the general point above? Note that there could be,
regardless of where consensus lies on the generic question.

FWIW, my own answers for these are that its probably a better
plan today to not have (or make MTI) these null confidentiality
ciphersuites, and I don't know that hip would have any specific
reason to diverge from that. But I'd really like to see if
there is a modified consensus on this or not. (To be clear,
if there's not a new consensus then the current one would
seem to still apply here and I'll clear my discuss.)

Cheers,
S.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 08 Jul 2014 08:39:09 -0400

> shift the consensus away from having these or having

I should point out that I lobbied hard for CMAC and GMAC added to 5202, 
as they are better constructs for doing auth only, or so I have been told.

I seem to recall during this discussion not to add these options as we 
have NULL which we need anyway.  I argued back that for systems that 
have AES-CCM or GCM in hardware, there would be a desire for CMAC or 
GMAC over HMAC.  SO now we have 3 suites that provide auth only with 
selection based on what MACing works best for the system(s) in question.

So given this, NULL is to balance the auth only suites or what?

I should also point out that the code we have today may not be the only 
code we have tomorrow.  That NULL does provide a valuable test tool.

So finally, a best implementation practice may to caution parties to 
accepting NULL.  Perhaps NULL when it is the only offered option. Or 
NULL when the list only contains NULL, CMAC, or GMAC.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2014 16:24:32 +0100

On 08/07/14 16:06, James Cloos wrote:
> 
> If those doing IP over Amateur Radio are a use case, they require NULL.

That'd be IPsec, not IP, I guess. How many people actually
use IPsec that way?

For corner cases like that (and it is utterly a corner
case regardless of how laudable a corner case) I'd not
have an issue with there being some other RFC to which
they could conform, should there be sufficient interest
in writing such. I don't myself see that can ever justify
an MTI for all implementations though.

S.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 09 Jul 2014 10:48:50 -0400

Sent to the HIPSEC list from my HIPSEC user:

The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed 
payload, and in many use cases, the Initiator has pre-deteremined the 
Responder's HI and HIT so it can check the SIG before processing the ESP 
TRANSFORM parameters. In sensornets where the Initiator cannot 
pre-determine the Responder's (typically some sensor controller) HI and 
HIT, then it is a concern.

Further eventhough I1 is unsigned, the Initiator 'knows' what suites it 
wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC 
back, it MUST NOT complete the exchange. If in the R1 it gets NULL, 
CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC.

If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST 
NOT complete the exchange.

The HIP design team spent a long time working out downgrade attacks. I 
have to thank Tobias Heer and Miika Komu for a couple day design when I 
was visiting HIIT in Helsinki.

NULL, CMAC, or GMAC should only be configured as allowable suites when 
they are needed for debug, or the situation requires auth-only. And I 
should point out there are devices and situations where auth-only is the 
case, so those suites are needed. IMNSHO.

In the worst case scenario, we could cover with text that clearifies the 
privacy versus auth-only suites with requirements that these suites not 
be mixed in an exchange and if one is expected, the other not accepted. 
Of course 'servers' (I say that parenthetically, as HIP is a peer 
exchange) MIGHT need to support both classes of customers and thus need 
to respond based on the unprotectable I1 packet. Even there, the 
Initiator still can bid back if its I1 was altered by a MiTM.

---

From: Tom Henderson <[email-masked]>
Date: Wed, 09 Jul 2014 13:27:08 -0700

> Initiator still can bid back if its I1 was altered by a MiTM.

I would be fine with lessening this MUST to SHOULD.  We probably should 
do the same for RFC 5201 (the HIP CIPHER).

Below are some suggested edits along the lines of your suggestions 
above; any comments or concerns?

In Section 5.2.8 of RFC 5201-bis:

OLD TEXT:

    Mandatory implementation: AES-128-CBC.  NULL-ENCRYPTION [RFC2410] is
    included for testing purposes.

NEW TEXT:

    Mandatory implementation: AES-128-CBC.  Implementors SHOULD support 
NULL for testing/debugging purposes, but MUST NOT offer or accept this 
value unless explicitly configured for testing/debugging of the HIP 
protocol.

In Section 3.3.5 of RFC 5202-bis:

OLD TEXT:

    In addition to AES-128-CBC, all implementations MUST implement the
    ESP NULL encryption algorithm.  When the ESP NULL encryption is used,
    it MUST be used together with SHA-256 authentication as specified in
    Section 5.1.2

NEW TEXT:

    In addition to AES-128-CBC, all implementations SHOULD implement the
    ESP NULL encryption algorithm.  When the ESP NULL encryption is used,
    it MUST be used together with SHA-256 authentication as specified in
    Section 5.1.2.

    When an authentication-only suite is used (NULL,
    AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT
    be accepted if offered by the peer unless the local policy
    configuration regarding the peer host is explicitly set to allow an
    authentication-only mode.  This is to prevent sessions from being
    downgraded to an authentication-only mode when one side's policy
    requests privacy for the session.

In Section 5.1.2 of RFC 5202-bis:

OLD TEXT:

    Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL
    with HMAC-SHA-256.

NEW TEXT:

    Mandatory implementation: AES-128-CBC with HMAC-SHA-256.  NULL with
    HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5).

- Tom

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 09 Jul 2014 16:39:50 -0400

I am comfortable with these changes.

On 07/09/2014 04:27 PM, Tom Henderson wrote:
> I would be fine with lessening this MUST to SHOULD.  We probably 
> should do the same for RFC 5201 (the HIP CIPHER).
>

---

From: Paul Lambert <[email-masked]>
Date: Wed, 9 Jul 2014 13:42:51 -0700

³SHOULD² is a good improvement for those of us that may not be as fond of
NULL encryption.

---

From: James Cloos <[email-masked]>
Date: Tue, 08 Jul 2014 11:06:03 -0400

>>>>> "TH" == Tom Henderson <[email-masked]> writes:

TH> Stephen's discuss questions the specification of "MUST to implement"
TH> for the NULL encryption option of the ESP_TRANSFORM parameter:

Encryption is illegal for most of them (I hear Australia allows it in
some cases; AFAIK no other country does) but authentication has value.

And that restriction is enforced.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jul 2014 13:59:54 -0400

Stephen Farrell <[email-masked]> wrote:
    > Mandatory-To-Implement (MTI)? That clearly was the generic consensus as
    > we have these in a number of protocols. The new reasons to move from
    > that I think are: 1) we no longer need this for debugging purposes
    > really since libraries and dev tools have moved on and are better now,
    > and we specifically no longer need these for protocols that are no
    > longer new, 2) BCP188 could be considered to argue against having these

There are an incredible number of systems (Linux with stock-in-kernel NETKEY
IPsec for instance), where it is impossible or very very difficult to get a
packet capture of the traffic after decryption, but before it goes up the
protocol stack. 

On such systems, if you have a problem in the field with a protocol that runs
over ESP (whether HIP or IKEv2 keyed), and you can't figure out how it works,
and it appears to with without ESP, then the lack of debugging means that you
turn off all security.

ESP-authenticated-with-NULL-encryption is debuggable in the field.
Not having it, means turning off ESP; and if the problem is in the link
between the ESP layer and the upper layer, then... 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: James Cloos <[email-masked]>
Date: Tue, 08 Jul 2014 12:37:29 -0400

>>>>> "SF" == Stephen Farrell <[email-masked]> writes:

SF> That'd be IPsec, not IP, I guess. How many people actually
SF> use IPsec that way?

I don't know.  AIUI, hams have been specified as a reason for NULL for
most ietf work product.

For this case, though, it seems Robert's suggestion of CMAC and GMAC may
be better long term.

Although there is stil the issue of compatibility with existing users,
if there are any.

-JimC

---

From: Paul Lambert <[email-masked]>
Date: Mon, 21 Jul 2014 16:57:03 -0700

NULL may be useful to some, but should NOT be mandated (should rather than must).
It's another knob that could be set incorrectly and bypass the encryption.  Not all products will want or need NULL.

Paul

]-----Original Message-----
]From: Hipsec [mailto:[email-masked]] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: [email-masked]; [email-masked]
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <[email-masked]> wrote:
]    > Generic: is it still considered a good plan to have null
]    > confidentiality suites such as these? Or for those to be
]    > Mandatory-To-Implement (MTI)? That clearly was the generic
]consensus as
]    > we have these in a number of protocols. The new reasons to move
]from
]    > that I think are: 1) we no longer need this for debugging purposes
]    > really since libraries and dev tools have moved on and are better
]now,
]    > and we specifically no longer need these for protocols that are no
]    > longer new, 2) BCP188 could be considered to argue against having
]these
]
]There are an incredible number of systems (Linux with stock-in-kernel
]NETKEY IPsec for instance), where it is impossible or very very
]difficult to get a packet capture of the traffic after decryption, but
]before it goes up the protocol stack.
]
]On such systems, if you have a problem in the field with a protocol that
]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how
]it works, and it appears to with without ESP, then the lack of debugging
]means that you turn off all security.
]
]ESP-authenticated-with-NULL-encryption is debuggable in the field.
]Not having it, means turning off ESP; and if the problem is in the link
]between the ESP layer and the upper layer, then...
]
]--
]Michael Richardson <[email-masked]>, Sandelman Software Works  -=
]IPv6 IoT consulting =-
]
]

---

From: Henry B Hotz <[email-masked]>
Date: Mon, 21 Jul 2014 17:51:09 -0700

The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no".

My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST.

On Jul 21, 2014, at 4:57 PM, Paul Lambert <[email-masked]> wrote:

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

Personal email.  [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 10:28:43 -0400

> If those doing IP over Amateur Radio are a use case, they require NULL.

If Amateur Radio's prohibition on encryption is considered to be important in making decisions about crypto in protocols, then I think we are in a situation where we can't have crypto protocols that don't disallow downgrade attacks, because implementations always have to be willing to downgrade to no encryption if the other endpoint is an Amateur Radio station.

So, by reductio ad absurdum, I claim that this isn't something the working group should consider as a deciding factor.   I think the same observation also applies to Michael's comment about debugging on stacks with limited trace capability.   If you need to disable encryption, you should have to do something fairly extraordinary to make that happen.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Jul 2014 10:28:54 -0400

> The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

In this regard, I have a hard time distinguishing between NULL with 
HMAC-SHA256 and CMAC or GMAC.

With this (secure communications) context NULL means no privacy but yes 
authenticity.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Jul 2014 10:45:01 -0400

> So, by reductio ad absurdum, I claim that this isn't something the working group should consider as a deciding factor.   I think the same observation also applies to Michael's comment about debuggi…

It is a switch to request integrity only. Or to only allow integrity 
only. Either party MUST be able to reject an integrity only negotiation.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 10:49:48 -0400

On Jul 22, 2014, at 10:45 AM, Robert Moskowitz <[email-masked]> wrote:
> It is a switch to request integrity only. Or to only allow integrity only. Either party MUST be able to reject an integrity only negotiation.

That's not good enough.   It should be the case that integrity-only negotiations are rejected by default, unless there's no protocol requirement for confidentiality.   If there is no need for confidentiality, then the answer to the DISCUSS should be "there is no need for confidentiality."

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jul 2014 11:25:48 -0400

> If Amateur Radio's prohibition on encryption is considered to be
    > important in making decisions about crypto in protocols, then I think
    > we are in a situation where we can't have crypto protocols that don't
    > disallow downgrade attacks, because implementations always have to be
    > willing to downgrade to no encryption if the other endpoint is an
    > Amateur Radio station.

Ted, you are assuming that there are no policy knobs at all.
We are talking about IPsec ESP, as required by HIP, not UTA/TLS here.

I don't understand this fear that policy knobs will accidentally get
unstuck and start accepting something weaker without administrator
involvement.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jul 2014 11:26:48 -0400

> That's not good enough.  It should be the case that integrity-only
    > negotiations are rejected by default, unless there's no protocol
    > requirement for confidentiality.  If there is no need for
    > confidentiality, then the answer to the DISCUSS should be "there is no
    > need for confidentiality."

All of those knobs, correctly labelled, are all there already.  Really.

---

From: Edward Lopez <[email-masked]>
Date: Tue, 22 Jul 2014 15:28:52 +0000

In my view, the underlying question is concerned with the value of a common encryption algorithm across all implementations of ESP, NULL or otherwise.  In my experience, the existence of mandatory common denominators in standards results in improved interoperability between implementations.  In the particular case of ESP, I agree that virtually no one would implement IPSec using NULL encryption, and we heavily rely on de-facto common use of US NIST-approved protocols (DES, 3DES, AES) for interoperability today.

My point is that by removing the MUST requirement for NULL encryption, should be consider the idea that we are substituting a stated common encryption protocol for a set of implied ones.  We will also be eliminating implementation choices over time for those requiring NULL encryption.

I’m not strongly advocating keeping the MUST, and would likely be ok to replace it with SHOULD.  But I did want to state that this surrendering of an mandated algorithm, and its consequences relative to maintaining interoperability, is a factor that I considered.

Ed

On Jul 21, 2014, at 8:51 PM, Henry B Hotz <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 21, 2014, at 4:57 PM, Paul Lambert <[email-masked]<mailto:[email-masked]>> wrote:

Paul

]From: Hipsec [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael
]Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
]Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
]Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works  -=
]IPv6 IoT consulting =-
]
]

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

Personal email.  [email-masked]<mailto:[email-masked]>

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Jul 2014 13:34:28 -0400

> All of those knobs, correctly labelled, are all there already.  Really.

The code has the knobs, but Ted's question is does the spec have the knobs.

Something like

"default transform lists MUST NOT provide any of the integrity only 
suites.  These MAY be offered only by explicit configuration."

This discussion is about NULL which is quite a misnomer...

But back in the days.........

If you look at the HIP exchange, R1 contains the offered list, and I2 
either contains the requested suite, or a counter list.  Both are signed 
(in HIP-BEX) and thus can only be spoofed for anonymous HITs.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 13:49:33 -0400

> Ted, you are assuming that there are no policy knobs at all.

No, I am assuming that there _are_ policy knobs, and saying what I think their default values should be.

But to be clear, I would expect surfing the web legally over a ham radio link to be pretty unsatisfying, because you would get no encrypted content, and lots of content is encrypted.   I am saying that this should not change.