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

  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.

On Mon, July 28, 2008 2:58 pm, Yoav Nir wrote:
> 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.
>
> On Jul 28, 2008, at 7:04 PM, Dan Harkins wrote:
>
>>
>>  Hi,
>
> <snip>
>
>>
>>  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.
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec