Subject: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

From: Nico Williams <[email-masked]>
Date: Fri, 29 Jun 2012 18:21:10 -0500

On Fri, Jun 29, 2012 at 5:58 PM, Ted Ts'o <[email-masked]> wrote:
> <Blast from the past>
> One of the problems, which was recognized back when I was the IPSEC
> chair, althouh we were never able to do anything about it, was the
> bias that "IETF doesn't do API's"; in many ways the GSSAPI was the
> exception which proved the rule.  Part of the problem was not just the
> institutional bias, but also the fact that most IETF attendees back
> then (I can't really speak for now) didn't have API design as one of
> their strengths / core competencies.

That is changing now, but there's still a lot of resistance to APIs.
SCTP is another exception to the old bias.

> If we had designed a IPSEC API, much like the BSD Sockets layer was a
> defacto standard API to TCP/IP, I think it would have done a lot to
> help the situation.  That would have meant exposing things like x509
> certificate names in a sane, easy-to-use, and platform independent way
> via C bindings, which IMHO is still an unsolved problem, it would have
> made it a lot easier for applications to use IPSEC for end-to-end
> authentication.

x.500 naming is just not useful.  Humans can handle name@domain and
only slightly more complex name forms, but x.500 is impossible.  And
we're stuck with Name because that's what TBSCertificate uses for
subjectName.  We can't switch to GeneralName for subjectName.  We're
screwed.  I'm tempted to propose the use of UUIDs in subjectName and
then treat the first subjectAltName as the canonical name, banning the
use of Name, but that wouldn't fly either.  We're stuck.

> There still would have been major deployment challenges, and this
> might have not been enough (TLS still would have been easier from a
> deployment perspective, which is really important if you are an
> application provider/vendor), but IPSEC as an end-to-end application
> security mechanism would have at least had a fighting chance.

Yes.  We have taken one step in the direction of making IPsec usable
for e2e, namely we've defined a notion of "IPsec channel" (which is
much subtler than one might think due to the fact that IPsec deals
with in-practice-changeable IP addresses while apps deal in other
things.  See RFC5660.  The idea was that then we could have socket
options for doing such things as asking what the "name" (cert,
whatever) of the end-points of a socket are, specifying credentials to
use on the local side, specifying what a server's name must be or
trust anchors, say, what cipher suites to use, etcertera.  But
interest flagged.  The fact is that it's too late for IPsec.  There
are very few Internet applications that only support the use of IPsec
for end-to-end session cryptographic protection (iSCSI, I'm looking at
you!), and chances are there won't be any more.

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 30 Jun 2012 16:04:42 +0300

This is highly speculative, highly subjective of course, but I don't 
think an API would have gotten IPsec to dominate the world. On the 
contrary, app developers are happy to focus on their own stuff and not 
spend too much time on security.

 From an application point of view, TLS has two important advantages 
over IPsec (IKE really):

- The well known advantage is that TLS is usually happy to authenticate 
only the server, leaving client auth to the application. This makes 
deployment so much easier.

- The dirty little secret is that many people do not even authenticate 
the server. In the cloud computing space (today's Wild West?) I have 
seen several cases of popular tools that just don't bother, with no 
apparent justification that I can think of. Another example is EAP-TLS 
configuration on Windows.

I'm not trying to imply that TLS is insecure. But clearly if widespread 
deployment is a goal (and it should be, otherwise why bother writing 
RFCs) you should let deployers/developers choose their appropriate level 
of security. In some cases, sadly, they will make the wrong choice.

Thanks,
	Yaron

On 06/30/2012 02:21 AM, Nico Williams wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>