Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme)

From: "Dan Harkins" <[email-masked]>
Date: Mon, 28 Jul 2008 11:04:47 -0700 (PDT)

Hi,

  I'd like to take issue with part of this charter, specifically the
session resumption part.

  I'd like to see the work not be so "remote access" and "client" centric.
It's more of a generic problem and should have a generic solution. This
might just be a semantic hangup of mine (which is easily taken care of)
but I'd just like to ensure that the remote access slash VPN focus doesn't
constrain things.

  A bigger issue, though, concerns the construction of the "ticket". I'd
like to know why this is out-of-scope. I can see the possibility of
consensus forming in the WG around a document that does not specify
construction of the "ticket" but that doesn't mean the topic should be
out-of-scope. How the "ticket" get constructed will influence the security
of the scheme. A properly constructed "ticket" may even help address DoS
issues. This topic should be in scope. It seems very wrong that we would
generate a standards track document in the Security Area with a critical
component of the security of the proposal being left up to the imagination
of the guy implementing it.

  I've been going through the last couple weeks of postings and can't find
discussion and/or justification for making "ticket" construction
out-of-scope.

  regards,

  Dan.

On Tue, June 24, 2008 9:30 am, IESG Secretary wrote:
> A new IETF working group has been proposed in the Security Area.  The IESG
> has not made any determination as yet.  The following draft charter was
> submitted, and is provided for informational purposes only.  Please send
> your comments to the IESG mailing list ([email-masked]) by Tuesday, July 1,
> 2008.
>
>
> IP Security Maintenance and Extensions (ipsecme)
> ------------------------------------------------
> Last Modified: June 19, 2008
>
> Current Status: Proposed Working Group
>
> Chair(s): TBD
>
> Mailing Lists:
>
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
> Archive: http://www.ietf.org/mail-archive/web/ipsec/
>
> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
> RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
> security architecture (RFC 4301). IPsec is widely deployed in VPN
> gateways, VPN remote access clients, and as a substrate for
> host-to-host, host-to-network, and network-to-network security.
>
> The IPsec Maintenance and Extensions Working Group will continue the
> work of the earlier IPsec Working Group which was concluded in 2005. Its
> purpose is to maintain the IPsec standard and to facilitate discussion
> of clarifications, improvements, and extensions and improvements to
> IPsec, mostly to IKEv2. The working group will also be a focus point for
> other IETF Working Groups who use IPsec in their own protocols.
>
> The initial set of work items is:
>
> - A revision to IKEv2 (RFC 4306) that incorporates the clarifications
> from RFC 4718, and otherwise improves the quality of the specification,
> taking into account implementation and interoperability experience. In
> some cases, the revision may include small technical corrections;
> however, impact on existing implementations must be considered. Major
> changes and adding new features is beyond the scope of this work
> item. The starting point for this work is draft-hoffman-ikev2bis.
>
> - An IPsec document roadmap that describes the various RFC documents
> covering IPsec, including both the core RFC 240x and RFC 430x versions
> of IPsec, and extensions specified in other documents. Sections 2 and 3
> of RFC 2411 can provide useful material, but the expected scope is
> slightly different from RFC 2411. This document will be informational.
>
> - A standards-track extension to IKEv2 that provides full IPv6 support
> for IPsec remote access clients that use configuration payloads. This
> work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall
> solicit help and reviews from the 6MAN WG to ensure that all aspects of
> IPv6 are properly considered.
>
> - A standards-track extension that allows an IPsec remote access client
> to "resume" a session with a gateway; that is, to skip certain parts of
> IKE negotation when connecting again to the same gateway (or possibly a
> cluster of closely cooperating gateways). The idea is similar to TLS
> session resumption without server-side state, specified in RFC 5077.
>
> The main goals for this extension are to avoid public-key computations
> (to reduce VPN gateway load when a large number of clients reconnect to
> the geteway within a short period of time, such as following a network
> outage), and remove the need for user interaction for authentication
> (which may be required by some authentication mechanisms). The extension
> shall not have negative impact on IKEv2 security features.
>
> Failover from one gateway to another, mechanisms for detecting when a
> session should be resumed, and specifying communication mechanisms
> between gateways are beyond the scope of this work item. Specifying the
> detailed contents of the "session ticket" is also beyond the scope of
> this document; if there is sufficient interest, this could be specified
> later in a separate document.
>
> To the degree its content falls within the scope of this work item, text
> and ideas from draft-sheffer-ipsec-failover will be used as a starting
> point.
>
> - A standards-track extension to IPsec that allows an IPsec remote
> access gateway to redirect VPN clients to another gateway. This
> extension should be aligned with the session resumption extension,
> (the previous work item), and if so decided by the WG, could be
> specified in the same document. The starting point will be
> draft-devarapalli-ipsec-ikev2-redirect.
>
> - A standards-track mechanism that allows an intermediary device, such
> as a firewall or intrusion detection system, to easily and reliably
> determine whether an ESP packet is encrypted with the NULL cipher; and
> if it is, determine the location of the actual payload data inside the
> packet. The starting points for this work item are
> draft-grewal-ipsec-traffic-visibility and draft-hoffman-
> esp-null-protocol.
>
> The initial scope of the WG is restricted to the work items listed
> above. The WG shall not consider adding new work items until one or more
> of its documents progress to IESG evaluation. At that time, the WG can
> propose rechartering.
>
> Chartering this WG is not intended to have effect on documents that
> beyond the initial scope. In particular, work on IPsec extensions that
> are not included in this charter can happen as usual in other WGs (and
> there are currently several other WGs working on IPsec extensions; for
> example, BTNS and ROHC), or as individual submissions.
>
> This charter will expire in July 2010 (24 months from approval). If
> the charter is not updated before that time, the WG will be closed and
> any remaining documents revert back to individual Internet-Drafts.
>
> Milestones:
>
> Dec 2008 WG last call on IPv6 configuration payloads
> Dec 2008 WG last call on IPsec roadmap
> Jan 2009 WG last call on session resumption
> Feb 2009 WG last call on redirect
> Mar 2009 WG last call on IKEv2bis
> Apr 2009 WG last call on ESP NULL traffic visibility
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 28 Jul 2008 19:23:44 +0100

Hi Dan,

I certainly have a remote access slant on this. My rationale is that you 
can have 100,000 clients to a RA gateway, but you rarely if ever have 
similar numbers in symmetric peer-to-peer IPsec. But I'm willing to be 
convinced otherwise.

Regarding the ticket, we are in violent agreement. The trick is to 
design the ticket well enough to ensure it is used securely, while still 
allowing each vendor the freedom of defining their own IKE/IPsec state. 
The current draft is somewhat over-specified. I think all we need is (1) 
the minimal contents of the ticket, i.e. what pieces of the IKE state 
are required to be there and (2) how the ticket should be protected.

Thanks,

    Yaron

Dan Harkins wrote:

> Scanned by Check Point Total Security Gateway.
>
>

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 28 Jul 2008 12:02:12 -0700 (PDT)

Hi Yaron,

  I concede that your problem is maybe 3 orders of magnitude greater
than what I'm thinking about but there can also be cases of a "host"
speaking transport mode IPsec to a couple hundred or more other "hosts"
and a standard SA resumption mechanism would be beneficial. I also think
it would be good if it worked both ways, that is either side or maybe both,
could produce a "ticket". As long as this is just a semantic issue and it
doesn't constrain the protocol I think we're fine but IPsec is not a
remote access protocol and I don't think it would be good to extend it in
ways that were solely remote access.

  I'm glad we're in violent agreement on the ticket construction. So how
do we get this topic in scope?

  regards,

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Jul 2008 22:58:59 +0100

I don't really agree with this. Different vendors would want different  
things in the "ticket". So much so, that if we insist on including it,  
one of two things will happen: (1) We will fail to reach consensus or  
some vendors implement their own private version, or (2) We will end  
up with a monstrous structure with IETF-specified and vendor-specific  
extensions.

Just as a for-instance, I'll give some examples of what may or may not  
be in the ticket:
1. My company makes VPN software that runs of commodity servers. These  
servers run on regular X86 processors and come with 100's of gigabytes  
of disk space. It's fairly easy for me to save the IKE SA to disk upon  
its creation, perhaps in a database with a unique 64-bit key, and send  
that 64-bit key as the "ticket". After a crash, the database is still  
there. Other vendors run on systems with either no disk or very  
limited disk space, sometimes flash-based. They can't store their SAs  
on disk.
2. With AAA servers you sometimes get authorization information from  
the server during the log-in process. In such a case, the ticket (or  
its persistent record) must hold the authorization information (you  
either can't or don't want to query the AAA server for that  
information during resumption). Other vendors may not rely on AAA  
servers for authorization.
3. User identity may sometimes be stored as a simple string (ASCII or  
UTF8), as a DN, as an email address extracted from the DN or from an  
alternate name in the certificate, or we may want to keep the user  
identity as their public key.

Since failover from one gateway to another is out of scope, let alone  
a failover from one gateway to a gateway made by a different vendor,  
interoperability does not suffer by not specifying a ticket. We can  
and should specify security considerations and what data the gateway  
should be able to reconstruct based on the ticket, but format should  
be out of scope.

>  Hi,

<snip>

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 28 Jul 2008 16:19:14 -0700 (PDT)

Hi Yoav,

  I don't want to dictate the components of the ticket to vendors.
The components of a ticket have to make sense to the recipient
(presumably the creator) of the ticket and in that sense it's a blob
opaque to all but the intended recipient. If you have special sauce
that accompanies an IPsec or IKE SA then, by all means, include the
special sauce in your ticket.

  There should be a minimum-- a key and any authorization information
bound to the key or that constrains use of the key-- but after that you
can add whatever you want.

  But for this to be a secure protocol there should be some security
requirements around the ticket. Such as:

    0. the ticket must be unforgeable.
    1. (a portion of) the ticket MUST be indistinguishable from random
       by everyone except the intended recipient.
    2. the ticket MUST be bound to a peer and it MUST NOT be possible for
       one peer's ticket to be used by another peer.
    3. the peer must prove knowledge of the key wrapped in the ticket
       when performing session resumption.

To enforce adherence to those requirements we should specify how the
ticket gets constructed (which is not the same as what it's constructed
with).

  Your example was to send the 64-bit index into a database as the ticket.
I'm sure that's not what you propose to do and was just an example but
it illustrates why we need some base requirements around construction of
the ticket. Such a ticket is forgeable and nothing binds a peer to such
a ticket. The scheme would probably rely on layers of checks ("is the
claimed sender of this ticket the same as the address in the SA pointed
to by this ticket index?", etc) to ensure the ticket isn't misused instead
of having a robust cryptographic check to ensure proper ticket usage.

  Another bad example of ticket creation would be to create a keystream
with a hash function, seeded with some password, and XOR the keystream
with each ticket to create the opaque blob. A naive implementor who is
not security savvy might come up with such a scheme. We should prevent
someone from claiming compliance with a standards track RFC from the
Security Area of the IETF if they have such a lame scheme.

  This is a security protocol and we should make sure it's secure. To do
so we should specify _minimum_ behavior to comply with reasonable security
requirements. A base blob communication protocol whose entire security
is left up to the imagination of the implementor is not what a standards
track RFC out of the Security Area of the IETF should be, in my opinion
anyway.

  regards,

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Jul 2008 03:07:29 +0300

> of having a robust cryptographic check to ensure proper ticket usage.

Running index would be perfectly good ticket and would be perfectly
secure. The initiator doing the resumption will give that ticket to
the responder, responder will look up the keys and other material from
the database, and then decrypt the rest of the encrypted message and
verify the integrity of it. After that it will mark the index in the
database as "used" so it cannot be used anymore. The initiator has
proven the knowledge of the key associated to the ticket (but not
wrapped in to the ticket, as it was in the database instead) by being
able to create the encrypted and integrity protected parts of the
message. Any other peer would be knowing the keys to generate
cryptographically integrity portected message so that should prevent
anybody else using the ticket (unless the original party of the
initial IKE SA creation gives out the keys).

I do not understand why the ticket must be unforgeable or why it must
be indistinguishable from random? Those requirements do not make any
sense for me in this kind of database case. Anybody can see the ticket
immediately when it is first time used and attacker just needs to read
the ticket from there and block those packets from reaching the
recipient and then he can use the ticket if that would be the only
protection on the ticket. The real protection is that only valid party
can create the cryptographacally protected part of the message. 

> Security Area of the IETF if they have such a lame scheme.

Yes, that would be very bad ticket.

The vendor could also post those tickets and their decrypted content
to the wikipedia for storage, and that would also be bad way to do
tickets, but I still do not think we need to add rules forbidding
that... 

> track RFC out of the Security Area of the IETF should be, in my opinion

But as has been pointed out the ticket might not be just opaque blob
communication, it could also be representated as handle to some
internal persistent data structure. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 29 Jul 2008 00:54:44 -0700 (PDT)

Hi Tero,

On Mon, July 28, 2008 5:07 pm, Tero Kivinen wrote:
> protection on the ticket.

A ticket has to be unforgeable to prevent someone from creating his own
tickets that would be accepted by a particular responder. If the scheme
allows forgeries then anybody can create SAs without actually going through
authentication. I don't think we want to allow that.

Indistinguishable from random, for some number of adversary queries, is a
yardstick by which to measure security. Any cryptographic system is
breakable, in principle, after enough time and effort. So "security"
becomes a function of the amount of time and effort an attacker must use
to break the system. If it can be shown that an attacker cannot gain an
advantage in breaking the system after X queries, and X is sufficiently
large (like 2^80 or 2^128), then one can quantify "security" to a certain
degree. That seems like a worthwhile thing to do.

>                            The real protection is that only valid party

That's not much protection. A protocol is flawed if an attacker can cause
two legitimate parties to think the protocol finished successfully while
generating different state. It violates the "Consistency Requirement" (see
Hugo Krawczyk's paper SIGMA for a very good description).

An attacker could manipulate IP addresses during this exchange and the
result would be that the initiator thinks the SA is between IDi and IDr
at IP address X and IP address Y, respectively. The responder thinks the
SA is between IDi and IDr at IP address Z and IP address Y, respectively.
That is an undetectable failure by both the initiator and responder
therefore that protocol is flawed. The attacker could also just record
the legitimate exchange and then play it back in its entirety from
different IP addresses. Yes, the attacker doesn't know the key but the
responder thinks it has an SA with someone who doesn't exist at the
place it thinks that someone exists. The protocol is flawed.

This is fixable but it requires specifying behavior in creation of the
ticket. Or it requires unfounded assumptions to be made about the security
knowledge of implementors-- remember, if it's just an opaque blob then
the creation and processing of it is entirely up to the imagination of
the implementor.

> Yes, that would be very bad ticket.

Yet if the ticket is just an unspecified opaque blob this is entirely
possible. It's possible for someone to correctly implement the protocol
and end up with an something that is flawed from a security perspective.

Security protocols should be robust.

> tickets, but I still do not think we need to add rules forbidding

That's a ridiculous argument. Publishing secret data anywhere serves no
purpose. The point being made is that someone can correctly implement the
protocol but since the security of it depends on critical decisions they
make the end result may not be secure. Therefore the protocol is not
secure, certain implementations may or may not be secure but the protocol
is not.

But if the protocol had cryptographic checks built in such that the
man-in-the-middle, or replay, attack above would result in a verification
failure of the ticket then proper implementation of the specification would
result in some level of security. We could actually describe some security
features of the protocol.

> internal persistent data structure.

It could. But then, again, it could not. And even if it was, so what?
That doesn't make it secure. If construction of the ticket is out-of-scope
then you can't say what the ticket might or might not be. It can be
everything and anything, secure or insecure. All would be equally
acceptable. And that seems so very wrong to me.

  regards,

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Jul 2008 11:31:44 +0300

> authentication. I don't think we want to allow that.

Even when they can forge the ticket does not help them at all as they
do not know the keying material associated with the ticket, thus they
cannot create the encrypted and integrity protected parts of the
packet that is required to create SAs. 

> Hugo Krawczyk's paper SIGMA for a very good description).

Attacker cannot cause either party to think the protocol is finished
at all. Only the original parties can do that as they are the only
ones who knows the keys.

Note, that in this case both peers ALREADY have shared secret that is
used to calculate the integrity of the packet. Ticket is just used to
tell the responder who is the initiator, so he can use correct shared
secret key to authenticat the packet initiator sent.

I think you should really read the protocol document first, as I think
you are missing something big here.

> SA is between IDi and IDr at IP address Z and IP address Y, respectively.

And if X and Z are different then responder will ignore the Z as it
does not match the stored data in the database. Or if mobike is used
then the mobike payloads inside the encrypted parts will tell
both ends that there is NAT between them and they will work around it. 

> therefore that protocol is flawed.

Responder will detect this by comparing the outer addresses to the
database if no MOBIKE is used. If MOBIKE is used then both ends will
detect that NAT_DETECTION_*_IP notifies do not match, and there is NAT
between the peers, and will cope with that NAT (or in this case
attacker). 

> The attacker could also just record

If you read the protocol description it says each ticket is usable
only once. Thus after the legimate exchange is finished, the ticket is
destroyed and new one is created, i.e. in this case the ticket in the
database is marked as used and the responder issues new integer ticket
number for the initiator, and initiator will use that next time. 

> the creation and processing of it is entirely up to the imagination of

Yes. And we are here to specify protocols, not writing
implementations. Implementor can mess up things way easier, than doing
bad ticket generation, buffer overflows and such are much easier
mistakes to make...

> features of the protocol.

As nobody else than the implementor can have any way to verify that
those rules are followed (nobody else do not have the key required to
decrypt the blob), then mandating such things does not help, as if
implementor still wants to mess up things he can do so. Also rules
you put out forbids one of those very useful implementation
architecture. If the gateway has persisntent storage, it can store the
material there, and there is no need to use opaque encrypted blobs,
just the a handle to that persistent data. 

> acceptable. And that seems so very wrong to me.

Then we disagree here, and I do not think we should continue this. I
think it would be fine to provide example of good ticket generation
guidelines (like we do for example for cookies in the IKEv2), but
mandating anything for that kind of blob should be out of the scope.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 29 Jul 2008 10:46:06 -0700 (PDT)

> you are missing something big here.

That integrity-protected packet containing the ticket is what gets sent by
the attacker. That packet is not cryptographically bound to anything else.
While an attacker cannot create the packet, it can send that packet from
any IP address just as easily as a legitimate client can. This causes the
problem I discussed.

> both ends that there is NAT between them and they will work around it.

Except it doesn't say in the spec to match the address of the sender
against some external source.

So the security of the protocol relies on unstated checks. Is that the
only one or are there others? What is your aversion to using cryptography
to solve this problem?

> number for the initiator, and initiator will use that next time.

I read the protocol. It says, "Tickets are intended for one-time use: a
client MUST NOT reuse a ticket, either with the same or with a different
gateway.  A gateway SHOULD reject a reused ticket."

But attackers typically don't follow MUST and SHOULD rules in an RFC.
And a gateway upon receipt of a packet containing a ticket does not know
whether it's from a client who is faithfully following the rules or from
an attacker who is not.

A gateway can retain all tickets it has processed to make sure they're
not reused but for 100,000+ clients (to use Yoav's example) that gets
to be a burden. Or the protocol suggests making a "cookie request" to deal
with replay attacks. And in the event of a crash and restart 100,000+
resumption packets from 100,000+ clients will look quite a bit like an
attack.

> bad ticket generation, buffer overflows and such are much easier

So then let's not make it easier to mess up! What's wrong with a robust
protocol?

> just the a handle to that persistent data.

You said twice in your post that I should read the protocol. But you know
what? Maybe you should read the protocol. I'm not forbidding your "very
useful implementation architecture." Section 5.1 is doing that.

> mandating anything for that kind of blob should be out of the scope.

Yes, we do disagree. I want a protocol which uses cryptographic tools to
solve some obvious problems; you want to solve them by unstated and
non-cryptographic verification of external data. I want a protocol that,
when implemented correctly, can claim some well-founded security features;
you want a protocol that cannot claim any real security features.

If you think the spec should not mandate any particular construction or
behavior then fine, state that. We can disagree about what the spec should
say. But why make this topic out-of-scope? Why is robust security something
to be avoided ("if implementor still wants to mess up things he can do
so")?

I looked through the recent postings on this list and can't find anything
that discusses ticket creation as being out-of-scope. It just appeared in
the charter. Can someone please point me to the postings on the list that
discuss the rationale behind this? Where did this statement about
out-of-scope come from?

  Dan.