[siesta] Welcome, problem, and my approach

[Robert Moskowitz <[e-mail]>]

I want to welcome you all to the SIESTA list. I hope to get that siesta 
in when we finish this little project. Since I can use my naps these 
days, this means I got to focus for a bit to get the job done. I ask you 
to give me a hand here so we can get this done and get down to other 
business. Like that nap.

Please feel free to break this longesh post into pieces for your 
response(s). I wanted to get it all out at once...

Now that the standard IETF irreverence is out of the way, here is the 
problem statement that a few friends here have helped me work out:

PROBLEM STATEMENT

The present end-to-end application security context is tightly coupled 
with the underlying communication context. This is problematic for at 
least three reasons.


1) Not flexible: when the underlying communication context changes, the 
application security context must change, too.

2) Overhead associated with such coupling is prohibitively expensive 
over constrained networks (such as sensor or cellular networks).

3) Probably most important: an attack on the communication context 
immediately effects the application security.

I might add that because of 3, an attack that results in system restart, 
which restarts all communication context, also results in the need to 
restart security context.

GOALS

This work aims at a solution to the above problems, with the objective 
of providing security context and security message format(s) for an 
application,

1) which is fully decoupled from the underlying communication 
methodology and is thus resilient to attacks on the communication context.

2) With that, the security context may need to have basic understanding 
of the communication context to be efficient with datagram overhead and 
communication synchronization issues (such as sequence window 
management), and so it is desirable that solution supports the "hooks" 
into the underlying protocol


DIGRESSION

I have been in many sidebars comparing my concerns with tools we 
currently have created within the IETF. I contend that many of these 
tools fate share with the transport. TLS is strongly tied into the fate 
of the TCP state. Others are point solutions that, say IEEE 11073, 
cannot pick up and implement within 11073.20601.

Finally, why here? IETF is about networking and a session layer (i.e. 
messaging) technology seems to be out of scope. To that I have two 
answers. IETF has many session protocols, starting with this one called 
SMTP. Here is where the security knowledgeable people congregate. Here 
is where we can do the job right and provide a tool for other 
organizations to run with.

So now on to what I have seen as a way to accomplish this.

MAILING LIST WORK ITEMS

Define an envelope that will provide security protection for any 
message. As you will see, conflicting environments has led me to define 
3 formats, and I see a forth lurking around the corner.

Define how existing Key Management Protocols (e.g. IKE and HIP) will 
create the necessary security state and keys. And in fact, what is 
needed in terms of Security Associations at the session level and where 
does a Security Policy Database live in this context. I will add that it 
is up to the KMPs to create security context that will protect from MITM 
and other attacks, and to provide support for multi-player applications 
(e..g over multicast communications) as well as the more common 
two-party communications.

Define the session security machine that will live within a proper 
security boundry where the well defined session security state machine 
lives, accessed by a well defined API. With all the North-bound and 
South-bound software interface models I have seen of late, one might see 
this as a set of east and west bound interfaces with the KMP machine on 
one side and the communicating application on the other.


OTHER DISSCUSION POINTS

I have been asked about exposed, but authenticated message header 
formats. For example a communicating application over HTTP. I see this 
as a research issue as to whether the Additional Authenticated Data 
approach can be applied, resulting in some more formats. Though what 
little I understand of HTTP, I don't see this working for HTTP imbedded 
applications. Rather only their messages can be protect in this model.

What about mid-box awareness and exposed, but authenticated type 
information? First the Session Security Envelope (SSE, there I have 
named what I have been working on) format will be negotiated by the KMP 
just like they do for cipher suites and the like. So the participating 
communicating application know which format is used and thus how to 
process it. Any type information in a control byte(s) is for the benefit 
of outsiders. Since there is no protocol processing here, what for? I 
don't see it. I was given the case of extensiblity that ESP faced wrt 
WRAP. But with the 'ability' to define a new format and negotiate it 
within the KMP, I see this as a better approach than guessing what is 
needed for future extensibility. But I am open to being convinced.

The state machine/SSE service is a critical component in that it has to 
be complete, and secure. So do I have all the states, and can we well 
define the information passed between the communicating application and 
the SSE service and the SSE service and the KMP service.

So moving on.

ENVELOPE FORMATS and CIPHERSUITES

I have defined 3 SSE formats that vary based on the Envelope Length and 
the Sequence number sizes:

SPI (32 bits, to be consistant with existing KMPs)
Envelope Length (12 or 32 bits; 12 for constrained use)
Sequence number (20, 32, or 64 bits; note: this is the explicit size, 
the implicit size is 64 or 128 bits.)
Cryptotext (n bytes)
ICV (8 or 16 bytes)

The defined cipher suites are: AES with CCM, CMAC, GCM, or GMAC with 
either 8 or 16 byte ICV. I can see the free-for-all that has occured in 
general with KMPs of defining for every cipher that MAY be used by 
someone. Afterall, should we really trust AES and is it really the best 
(forget that it is built into MOST sensor hardware these days). And NIST 
may actually approve a stream cipher...

There is a lurking fourth format to work with Dave McGrew's new AERO 
cipher or any other similar cipher for highly constrained communication 
channels. This is for future work. Unless there is already a recognized 
cipher of this sort.


KMP NEGOTIATION

I invision the KMPs negotiating SSE in a single parameter that has two 
values: format and cipher suite. The combined values into a single 
parameter is to save on message length for constrained environments. 
Again I am open on this point. The KMP authors will address this.

What are the 'selectors' for the Security Policy Database (SPD). Does 
the SPD 'live' in the KMP or SSE service, or in the Communicating 
Application? I think the SA(s) are in the SSE service.

What else is need here?

SSE SERVICE/STATE MACHINE

The states I have defined are:

Start – call the KMP with the session identities and get the SPIs, key 
hierarchies, and ciphersuite

Key refresh – on seq # consumption, call the KMP for fresh keys

Secure – secure the message

Reveal – decrypt and/or authenticate the message

Teardown – tear down the security context

State machine needs to handle responder Security setup and state loss 
recovery (e.g. after reboot)
Some method is needed to connect a start or rekey with new SPIs to the 
SSE application that will use it. This could be internal to the KMP or 
KMP run over the eventual application port before any messages.


SECURITY SURVIVABILITY

This is important, but needs to be expressed carefully. Knocking over a 
server has to become uninteresting in a security sense. Time to restart 
or battery cost to restart are concerns. How best to achieve this? How 
to recommend best practice (eg how to use an HSM). Can hot standby work? 
Can security state be replicated across a group of servers? Securely? 
How tightly does seq# updates need to occur? Or is some form of 
multicast better? Definitely some intersting work here.


THE PLAN

Put together a writing team. I have a couple volunteers for writing an 
SSE draft. I will be contacting them tomorrow. If you are interested in 
helping with the writing, let me know. Also there needs to be specific 
KMP drafts and authors are needed for them.

And of course discussion here is always welcomed and SHOULD help focus 
on what to include, or not, in the documents.


Well this is a start. Thank you for joining.