Julien Laganier
2007-04-02 09:10:21 UTC
Folks,
Attached are the preliminary minutes of the BTNS
session at IETF68. Please send corrections/additions
to the mailing list before 2007-04-09 (next Monday).
-- Julien & Love
BTNS Chairs
-------------- next part --------------
---------------------------------------------------------------------------
BTNS working group meeting minutes
---------------------------------------------------------------------------
These are the minutes for the Better than nothing security (BTNS) working group
meeting, held at IETF-67 on Wednesday, Mar 21, 2007, in beautiful Prague, Czech
Republik. Thanks to the people who have implemented MP3 recording of the
session on which these minutes are based.
Chair: Julien Laganier <julien.ietf at laposte.net>
(Love Hornquist Astrand excused)
Responsible AD: Sam Hartman <hartmans-ietf at mit.edu>
* Agenda
Preliminaries - Chairs
Core and Connection Latching - Nico Williams
<http://www.ietf.org/internet-drafts/draft-ietf-btns-core-02.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-01.txt>
API - Michael Richardson & Miika Komu
<http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt>
<http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq-01.txt>
<http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-c-api-00.txt>
IKE Extensions - Michael Richardson
<http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ikeextensions-00.txt>
* Action items
- Chair to submit AS/PS to IESG for publication as Informational RFC
- Chair to issue WG Last call on BTNS Core document after meeting
- WG participants to read and comment connexion latching, API and IKE
extensions documents
* Narrative minutes for the session
---------------------------------------------------------------------------
Status update (Chair)
---------------------------------------------------------------------------
Missing couple of milestones, but chair confident that we can meet them soon.
AS/PS to IESG after the meeting.
Soon WGLC for core & connextion latching.
Soon adopt API documents as WG items.
---------------------------------------------------------------------------
Core BTNS (Nico Williams)
---------------------------------------------------------------------------
Slide 2: Change since -01
-------------------------
There's only two changes.
One was the changes made to the PAD SPD entries in the examples to remove
inconsistencies that Steven Kent pointed out. It's done, Steve can confirm.
I also reworded the bit about address accumulation. If you remember, we need
PAD entries to reject BTNS peers if their traffic selectors for their child SAs
could be asserted by non-BTNS peers. Better wording is to make two ordered
passes over PAD, one at authentication time, one at chid SA authorization time.
That's it for the changes.
Slide 3: Status: Ready for WGLC
-------------------------------
Status is I think it's ready for working group last call.
Questions?
I thought it was ready for working group last call modulo Steve comments,
so Julien I would ask for working group last call.
Actions: Chairs will issue WGLC.
--------
---------------------------------------------------------------------------
Connexion Latching (Nicolas Williams)
---------------------------------------------------------------------------
Slide 2: What
-------------
Connexion latching, it's sort of... It's to IPsec as TCP is to IP. It protects
packet flows coherently, not just packets. Kind of like TCP builds byte
streams out of packets. Alternatively it's a way to build IPsec channels.
It's needed because channel bindings needs IPsec channels.
In addition there's a desire to protect against change in
policy. Helps to address the problem where the PAD and SPD
policy allows multiple hosts to claim address from the same
networks Finally this is a fundation to IPsec APIs Questions:
Slide 3: Why
------------
We need it because you know for things like channel binding, we need IPsec
channels. In addition there is a desire to protect against a policy changing in
such a way that it will compromise packet flows. Also, it helps to address the
problem we discussed both in Montreal and I think in Vancouver, or wherever it
was, two meetings before, where you know, the PAD has an SPD policy basically
allowing multiple nodes to claim addresses from the same network making it
possible to steal each other's packets.
Finally, it's a foundation for IPsec APIs, and it's also sort of described
in terms of ... IPsec APIs.
Slide 4: How
------------
The idea is that when a connexion creation trigger occurs... in UDP you may
still have something like a packet flow, but it's not a connexion, think of
connected UDP sockets in BSD socket API... So what you do is that you figure
out what the peer ID is, and what kind of SA protection, ESP, whatever, what are
the algorithms, etc., and make sure that all subsequent packets for that packet
flow are protected by similar SA.
If you find packet from same packet flow which isn't protected, you drop. If
you want to send packet but don't have an SA, you drop.
On connexion tear down, you tear down the latch.
Slide 5: How
------------
The draft sketches two implementation designs, you don't have to do it in
either of these ways.
In approach #1, you record latch in upper layer protocol TCB, communicate
incoming/outgoing packet SA parameters between IPsec layer and ULP, effectively
tags packets as they move up/down in the stack
In datagram-oriented applications the latch would have to... Well, in
datagram-oriented applications, if the user connected socket, UDP socket, they
have to enforce latch.
Then in approach #2, you record the latch in the PAD and SPD and enforce the
latch at the IPsec policy layer.
Slide 6: Approach #1: Intimate Interfaces
-----------------------------------------
So approach #1 is the intimate interfaces, it effectively involves having
interfaces between the ULP and IPsec, and you know, we need a mean to say, hey
tell me how you protected this outgoing packet, and this incoming
packet was protected like so, and protect this packets like so.
Slide 7: Approach #2: PAD-based latching
----------------------------------------
PAD-based latching is a little more complicated, it basically requires ULP to
create create template PAD entry. For listeners we create 3-tuple template PAD
entry. For initiators we create 5-tuple PAD entry
Packets that match a template PAD entry cause an actual PAD entry to be
created. The child SA constraints are populated from the packet. The peer ID
populated from the SA that protected the incoming packet.
And on connection tear-down you have to remove the cloned PAD entry.
Slide 8: Properties
-------------------
Approach #1 works for connection-oriented and
non-connection-oriented ULPs. For UDP applications can connect UDP sockets, or
they can record and enforce the latch through ptokens, which is something we'll
see in Michael's presentation, or sendmsg/recvmsg.
The approach #2 also allows for UDP, but only in connected state. Approach #2
also needs a TIME_WAIT like state. This is because the tear-down of the flow
and latch have to be atomic with respect to new flow triggers. The wait time is
given by local latencies only, how long it takes for packets to move up and down
in the stack.
Slide 9: Properties
-------------------
But of course approach #2 is very close to RFC4301 model and if you have a NIC
that say provides ESP/AH/SPD offload but which don't provide a way to tag
packets, then you need to do something like approach #2.
Slide 10: APIs
--------------
At it's simplest this is just the traditional connect()/accept() BSD
socket-type APIs and they can work connection latching without the application
even knowing.
Slide 11: APIs
--------------
But IPsec APIs can give applications much more power. Who am I really talking
to, what is their IPsec ID, not their IP address but what is their certificate,
or what IP did they assert. Specify/verify that a connection's QoP meet/meet.
We can check whether the latch is ESP, AH, algorithms... We can do
leap-of-faith if we know the peer public key, and so on. So you see this in
Michael's and Miika's presentations and their I-Ds.
Slide 12: BYPASS OR PROTECT
---------------------------
Finally there's something that I don't know if it belongs to this draft or not.
It's BYPASS or PROTECT. Basically for some things it would be nice if you
could have the notion of optional IPsec protection so the example that I give
there is BYPASS
If you want to be able to leverage IPsec, you want to say hey if you can, give
me IPsec, and give me channel bindings, and we'll do channel bindings with the
RPCSEC_GESS layer.
Well if you can't do IPsec....
If we can negotiate this use of IPsec, great, so I call this BYPASS OR PROTECT.
In Approach #1 this is handled by the ULP or the application, you still need some
sort of SPD entry that says BYPASS OR PROTECT and the application knows what to do.
In Approach #2 this requires the same sort of things and some more.
Slide 13: BYPASS OR PROTECT
---------------------------
So in approach #1, the ULP and application is responsible.
In approach #2, we need to have some sort of template SPD entry, and that works
kind of like the template PAD entry that I described earlier. When a matching
packet arrives, unprotected, clone a BYPASS entry for just that 5-tuple. When
a matching packet arrives protected clone a PROTECT entry for just that
5-tuple. The ULP has to tear these down when the flows end. On outgoing flow
initiating packets the application must tell the system what it wants really,
and it must be able to do with IKE timeouts. So okay I'm not getting an IPsec
protection, so I just close that socket.
Slide 14: BYPASS OR PROTECT
---------------------------
So this is the example I gave before.
That's it.
Questions: I should point out that there are implementation of connexion
latching today, and some minimal set of APIs. If you use Solaris you can look
at the man pages for ipsecconf(1M) that describes connexion latching and tells
you that if you change policy your changes won't affect existing latching.
And then the ipsec(7P) man page tells you what socket option you can use to
request or check what algorithms are used, but you don't get to see what peer
identities are used so it's a small primitive API. I think KAME also has an
implementation although I'm not sure.
Questions:
----------
Chair: Who read the draft?
-> Two persons.
Chair: Please read the draft and comment on the mailing list.
---------------------------------------------------------------------------
C-Bindings for BTNS APIs (Miika Komu)
---------------------------------------------------------------------------
Slide 1:
--------
Hi everybody, My name is Miika Komu and I'll present work i did with
Sasu Tarkoma, Nicolas Williams and Michael Richardson.
Slide 2: What Problem Are We Solving?
-------------------------------------
So the problem that we are solving in practice is how do we make application
IPsec awarer. How can an application know that a connection is secured by
IPsec? How can the application tell to use the BTNS extensions. How to do
this using the C language with the socket API.
Slide 3: Diagram
----------------
We are interested in two kind of applications, the ones that use only the
IPsec API, and then application that also use TLS, GSS or SASL APIs.
Slide 4: Relationship to GSS/SASL
---------------------------------
So what's the difference then with these higher layer APIs, GSS and SASL. The
fundamental difference is that they are not using socket descriptors. The IPsec
API is tightly bound to socket descriptors, and can be used simultaneously with
GSS and SASL.
Slide 5: Policies
-----------------
Here are the functions for handling policies. There are some accessors to
create and get policies...
Slide 6: Channel Bindings
-------------------------
... and the same for channel bindings.
Slide 7: Changelog from 00 to 01
--------------------------------
And this is the changelog from 00 to 01... These are the old slides, I submitted
new ones, but never mind. 00 only contained ideas, but now there's some
concrete interfaces in the draft. Nico, Michael, Love and Julien have given me
lots of feebdack.
Slide 8: Todo list 1/3
----------------------
Todo list is quite long, so anyway it means some more code examples, and
definition of error values.
Slide 9: Todo list 2/3
----------------------
I'll fix the terminology in next version, the constants will be strings...
Slide 10: Todo list 3/3
-----------------------
Comparison functions for attributes to see if one protection is stronger than
another, but I am not sure it is needed. Then more attributes definitions, and
also conversion fucntions so that we can get human readable. Also lot of
editorial corrections.
These were actually the minimal version of the slides, I submitted longer slides.
Questions:
----------
Sam Hartman: You should submit slides you actually presented during the
session. Please make sure you don't overwrite these with newest version.
Chair: I'll send a link to the updated slides to the list, but proceedings will
contained presented version.
Chair: How many people read the draft?
-> Not too many
Sam Hartman: One thing would be to encourage reviewer to make sure that
anything in this API is consistent with RFC4301.
Michael Richardson: Sam when you say everything should be consistent with 4301,
there are three interpretations I can take with that. Which is that a 4301
implementation, all 4301 implementation implement everything in here? Or that
everything in here can be done by some subset of 4301? Or in fact does not
contradict with 4301 but may in fact extend it so that strictly 4301
implementation may need to be extended to implement this specification?
Sam: I propose that any... so first one, must not contradict 4301, that's
clearly important that you know for example you should not be able to... so for
example 4301 doesn't permit an implementation to... 4301 does not really have a
concept of optional encryption like... I mean things like connexion latching,
today I cannot say that it's okay for some people on application 1234 to use ESP
and for some people it's okay not to use it. I can't express that.
Michael: Right, that would be an extension.
Sam: That would be an extension.
Nico: But extensions are okay?
Sam: No... Okay, Steve is actually going to argue that this is not an
extension, Steve is going to argue that this is a fundamental change. So
certainly no fundamental changes, and we can have debates about what they are,
but I think Steve is going to be pretty firm on that one, that particular one.
Another thing is that, it would be nice if there were no... I would say that
extensions that are not covered by 4301 would be bad... for example 4301 ...
like SPD selection functions, and so if you wanted ... that would be fine, if
you wanted things that are beyond 4301 I don't think they should be specified
here, they should be specified as part of another document. Things in 4301
should be sufficient to implement API.
Nico: I don't know, why?
Sam: I don't think...
Michael Richardson: But the whole point of this whole effort is that people
want to do things that they can't do with just 4301. The whole point is that
we're trying to make applications that want to do things beyond that able to do
things. So limited to what 4301 says you can do, which does not say anything
about API, so we can't have an API with that argument. So clearly that's not
what you mean. The biggest issue is how do you interface there, and actually
Nico has addressed that in details in his draft on connexion latching, how do
you implement things, and actually there's one version of how do you implement
things that makes it much more difficult to do the things but it's possible to
do that with BITW or BITS implementation using relatively stricts 4301
concepts, although they may need the PROTECT OR BYPASS concept to be able to
cope with that. So with the additional, with the internet connexions to the
upper layer protocols we actually don't need or want to really go through all
of the 4301 mechanisms, we don't have to because we did a classification by
virtue of the fact that, particurlarly in the downward direction, by virtue of
the fact that we created the packet with knowledge of the SA we want to go in,
and that's pretty much it , and we also know in the TCP sockets which SA
specifically was supposed to be received on. So we actually don't need to go
and look at what the actual values were and Steve Bellovin has argued that
actually it's completely irrelevant what they are, what matters is the crypto
check determining whether the packet should be accepted by TCP. To not check
is an extension, but we don't need to say whether or not you go with that
effort so some of the rules in the processing instructions can be implicitely
skipped and there's some interesting advantages in doing that but functionally,
the functions are still there because TCP rejects packets from non originating
destinations anyway. So that's the question when you say, is it consistent with
4301, well we're saying that we get the same result if you implement it that
way, but we're not saying we work forward identical.
Sam: Steve, I am correct that you object as much as I think to the PROTECT OR
BYPASS concept?
Steve Kent: When we set up the working group initially we did had a long
discussion on important features of providing BTNS functionality. An essential
feature was to not undermine the access control functionality of an end system
doing simultaneously BTNS and conventional IPsec protection, so I think the
burden is on people writing these documents to explain how that is still
satisfied, rather than you know picking an individual issue here, it's to show
that when the thing is set-up, the criteria is still met.
Nico: Ok. And I think nothing in connexion latching undermines access control.
So connexion latching can be done without any API, sure. BYPASS OR PROTECT is
not needed if you do connexion latching without any API. However there is a
class of applications which today do one thing and which might do something
different if they could use IPsec. They might be able to say "hey, can we get
IPsec?" and if not let's do not IPsec. That's the only place where BYPASS OR
PROTECT comes in. And that would be done using port selectors that narrow
packet flows significantly only to these applications that know how to handle
this. Therefore I think no access control feature of 4301 model would be
violated.
Sam: Ok what Steve said today is much broader that what he said last time. I
think Steve... there is ... so ... I don't think that the API document should
be defining extensions to IPsec, I think that those should be somewhere else
and that the API document should be defining an API to use extensions that are
defined elsewhere. I am asking for architectural cleanliness
Nico: This particular extension is something that connexion latching...
Sam: I am not talking about connexion latching.
Nico: No, BYPASS OR PROTECT I guess?
Sam: No, I'm talking about the API document.
Nico: Ok, the API document does not specify extensions.
Michael: Well if we continue, my talk will try to show another direction, and it
will probably get more clear where we're going. We should actually have done
the talks in the reverse order.
Nico: Right because Michael's API is the abstract API, not the C API.
Chair: So maybe Michael you present the abstract API now...
Michael: Yes.
---------------------------------------------------------------------------
BTNS API proposal overview (Michael Richardson)
---------------------------------------------------------------------------
Actually I should but Bill Sommerfeld's name on these slides too.
But I'm not so sure if he's still alive, I've heard he is but couldn't talk to
him.
Slide 1: Three objects
----------------------
Oh yeah, these are also not the last version.
So, on Monday Nico convinced me to add this third bullet, on Tuesday he
convinced me to remove it. So essentially we have two objects and we concluded
that the third object was not a first class object but was rather an attribute
of the second object. We have protection Token, that deals with the details of
one session, so if you like you can link it to an IPsec SA. We don't really
want to tell that the application knows too many details of that, but that's
the kind of thing, they are specific to an SA, protection tokens have no scope
outside of the process you're running in, don't expect to put them in a Jabber
channel and have someone else knows what they mean or anything like that. So
they're very very specific, they have some attributes, some of these attributes
could be things like strength and key size and things like that. Absolutelly
never the actual keys, they would never be revealled. And anyone who did that I
think deserved to be slapped.
Then we have identity tokens, identity tokens are... I take a protection
token, you can get from that an identity token. An identity token somehow maps
to something like a certificate or other type of things, and may have what
we created what this crededntials token, and this is the notion that may tell
you where to get your private key, specifically in the case where they might be
offline, or in a kind of smartcard or something like that.
Slide 2: Connected sockets
--------------------------
So let's just talk about you how get things, and this maps a little bit to the
details like the C-bindings that Miika has worked on.
So let's talk first of a connected sockets, so TCP, SCTP, or UDP sockets that
call connect(), so basically we're not going to change I/O operations basis.
Initiator for these things is the end that calls connect(), and we suggest for
simplicity and describing the whole situation that you also think of it as such
because it called connect(), it also created the first packet, and therefore
caused IKE to do something and create the IPsec SA. Clearly that connexion
doesn't have to be here but it will make things much simpler for everyone to
understand.
The acceptor is the end that calls accept(), and therefore becomes the IKE
responder, and it's the IKE responder before the accept() call terminates so
this is important because the responder really doesn't know its policies until
after it gots the connexion, and the initiator of course would like to express
its policies before the connexion occurs, but it may actually not know the details
until after it completes, ok?
Slide 3: Use case #1
--------------------
So use case #1, call connect() as an initiator, and accept() as an acceptor,
and you didn't say anything special, and you say okay get my protection token
from the file descriptor that I got from this process, so in accept that's a
brand new file descriptor connected. Then you say okay get my iToken from the
pToken, and this tells me essentialy, from the cryptographic point of view, who
I am connected to. And if I like I can take a channel binding out of that, feed
it into my GSS API, connexion latching, do things like that, ah excuse me, into
the channel binding and I'm pretty much set ok? This assumes that the reason
why the system to setup an IPsec tunnel was determined by the system somehow,
so there is PAD entry, an SPD entry that said, when you talk to this host or
when you speak to this protocol or any number of various selectors that we have
in the system, said I want to do IPsec for this connexion, so no contradiction
no new things here, just IPsec occured for some reasons beyond the
application's knowledge and the application now can find out that in fact it
did happened. This case does not distinguish between the case where it might
happened, like BYPASS OR PROTECT, we don't know the situation we don't know
that there may ever be cases where it's not accepted. But if didn't go through,
we didn't have IPsec, we'll find out at one of these two points that there was
no IPsec there.
Slide 4: Use case #2
--------------------
So use case 2 is initiator, so you said get me the identity of my remote guy
bob with whom I wanted to talk to, and get a protection token, and this should
be essentially use my default identity whatever that is, I'm not going to tell
you, you figure out, you know, who I want to talk to, that's bob identity. At
a high level that might be a DN, that might be a raw public key, that might be
an IPsec address, or something else. At this level of the abstract API we're
not really going to care about that.
I have a file descriptor, I got it from my socket call, it's a newborn, I set
my protection token on this. What does that mean at the bottom level? That means
probably some kind of a template PAD entry goes into place, probably something
that has everything relatively well specified except for the originating ports.
Maybe it's a populate-from-packet...
Sam: You mean SPD entry?
Michael: Yeah I mean SPD entry, I'm sorry. And it calls connect(), and crypto
happens.
Acceptor is like use case 1, if you like... that call the connect call...
Nico: It's actually a template PAD entry as I described in the connexion latching
presentation, because we're saying we're trying to constrain the address in the
selector for the child SA for this packet flow for what happened to a protected
perr, and that happende in the back
Sam: And in the SPD?
Nico: And in the SPD, but specifically it happened in the PAD...
Michael: That's why I wrote in my notes SPD/PAD, and I didn't really sort out
what these things really are in my head, I just noted that I have a template
that means the right thing.
Emphasis that these are standard unpriviliged calls, there's some details as to
what extent an unpriviliged application can override the system, that's to a
system level setting to decide, that's well into the realm of local policy, and
you should think about it, and take ... but I don't think this is a subject for
standardization or really great discussion here, except to realize that's
considerations that you will have to make.
Sam: I disagree, I think that we actually do need needs to get in this space
so that we can provide IPsec solutions for the protocols we standardize and people
can understand how they interact with locally configured SPD entries, and that's
something I talk a little bit about last week-end, and talked off-line to some
people.
Michael: So Sam, are you suggesting that we should have in our API a statement
explaining under what circumstances an unpriviliged appplication may overrides
a system policy?
Sam: I am saying that use of IPsec 4301 should talk about how SPD entries from
applications are combined with system SPD entries, and what ordering would be
used. Not in your document, but in use IPsec 4301.
Nico: But it is in IESG right now?
Sam: No just use IPsec 4301. You said IPsec 4301... It's out of scope of your
document
Michael: I understand your concern and I agree there's a concern and if you feel
there need to be a greater statement I would be doing that.
Sam: I think it's out of scope of your document.
Michael: Yes.
Slide 5: Use case #3
--------------------
So this is initiator only, I say: I like to talk to Bob. And I say:
By the way, on this multi-user system, my name is Alice (Francis or Julie).
Furthermore, and this becomes different than in the other slide, somehow I have
this magic PKCS11 session.
Nico: It doesn't need to be PKCS11.
Michael: Yeah, this is not the point, the point is that there's a real world
example where you've logged into your desktop, your computer is remote but your
crypto identity is actually local to you and the application can somehow access
to it, and furthermore can tell the IKE how to talk to it. So that's the
important part of it, that somehow this handle, it's like a file descriptor,
that somehow you tell IKE use that identity, and the resaon why I say I'm
Alice, that's because these are definitely the phase 1 ids that ared use in the
parent SA. So now I can do the right thing. I get a protection token and I tell
the system I want to use these things as part of it. I set the token on the file
descriptor and call connect(). So then the identity and the credentials are
determined by the application not the system.
Slide 6: Use case #4
--------------------
This is on the other side, on the Bob side. Bob has said "I want to tell the
guy I'm Bob", and on this socket when you respond you need to make sure that
you set identity, so you set that on the file descriptor, we call accept, and
afterwards you probably want to find out who connected to you, and do
something. But of course you have to set your identity to respond with.
Potentially there's an https problem here, where you can only have an identity
per port 443 - IP address combination, because the crypto happens before the
virtual host thing. There's no good solution to that, there were proposals some
time ago to have the iniator say which responder they wanted to talk to. But in
this case the issue is that they don't say I want to talk to Bob, I said I am
Bob. I am unclear what happens. Maybe this is not a problem that we need to
solve, just need to write the question. They connected to me they said they
wanted to talk to Frank, but only Bob is listening. What does it connect to?
are we allowed to have multiple listening on the same port number with
different security associations? That's an interesting system question that you
might ask.
Sam: So, what is the purpose of Bob saying who he wants to be to accept?
Michael: Well, listening to any application where there's a secondary data
port like FTP, you may have a situation where control connection has Alice
to Bob, and later on you open a data port for them to connect back again,
so you're trying to express that on that port to listen on you don't want the
system identity, but Bob's identity.
Sam: Ok, but in the case where you are not the initiator...
Nico: I have an answer, in practice this is odd because when somebody comes to
you as a responder, they don't tell you right the way who they want, what
selectors they're using.
Michael: Right, but from an IKE point of view, you hope to discover the mismatch.
Nico: Well but the only thing that really does is act as a fallback. And we
could get rid of it because the application can always do the filtering itself.
And we could also have a notification from IKE that said: Oh dude you really
meant Bob.
Sam: Actually I disagree, I think that's kind of the wrong way to deal with this.
I think that what this is.. It serves two purposes, first of all, it says make
this identity available, if people try to establish an IKE SA to Frances then
let's do that. The second thing it does is it should if it turns out that you
need to establish an SA in the reverse direction then it says who to use as your
initiator identity. I don't think it makes sense to make this peer filter on
one responder identity it already accepted. If you want that kind of filter, it
should be on initiator side. And Initiator can do that and say : I want to talk
to Bob. And if it can't get Bob, then that connect() fails.
Slide 7: Unconnected sockets (datagrams)
----------------------------------------
The next discussion is for unconnected sockets. You should think of this a
little bit as this is the interface between TCP connected systems and lower
layers.
Slide 8: Use case #5
--------------------
The protection, the people you're talking to can change on every packets. So
you can't just get the data independently of the packet. You can't use read()
or fread() calls to get this stuff out. You could get the identity out and
protection token on every packet you receive, so somehow you have to get it out
of the recvmsg() call, so I put it there but in reality it would come through
ancillary data. So you get that each time, itoken, ptoken, and in this case the
initiator identiy and credentail determined by the system. It's not clear for
unconnected if you can really set who I am expecting to be before I connect to
you. And you could do that again it would probably work. So you could set your
Bob identity.
Slide 9: Use case #6
--------------------
For the initiator you get protection token and you send the message with the
protection token. Now that may be a template ptoken. We don't think that
there's any guarantee that you could use the ancillary data cmsg as a value
result parameter. So you put the ptoken in, we're not sure how to get the
ptoken out again, the one that actually was used, the one that contains the
parameter of the session that was actually created as that message was sent.
Including non-templated PAD/SPD parts. So it's an open question how to do that
for this. I think that a number of systems could just happily do it, but I
don't think it's guaranteed by any spec we have. Again unprivileged calls.
Slide 10: Similarities to GSSAPI
--------------------------------
We intentionaly did this similar to GSSAPI. And in GSSAPI the ctoken has to be
first class object because there's no other context to associate with, because
GSSAPI just lives in whatever kind of bytestream. Use case 5 and 6 are not
easily implemented for systems using connection-latching section 2.2 "Latching
through PAD manipulations and extensions". If you are using "Intimate
interfaces between ULPs and IPsec" this is really easy to do, I actually
implemented it a year ago, for not actually for connected sockets, for
unconnected sockets where you cannot use any kind of standard selectors because
the host at the other end with the transport mode SA to .... The document that
I wrote should become the abstract API, and Miika's document should become the
C-bindings of the abstract API. This is fairly similar to the way GSSAPI did
it. Nico told me to my surprise that the GSSAPI documents were actually
standard track, not informational. We should ask the audience what do you
think? Any objection to the approach?
Sam: I think the abstract API presentation was very useful, we can solve
issues with 4301, I think this is a very good model. I think it's not
completely abstract...
Michael: I wanted to say is that the only thing you get to is the socket,
kernel is in charge of rest of the details.
Sam: I think it's a very good thing.
---------------------------------------------------------------------------
Wrap up (Chair)
---------------------------------------------------------------------------
Last presentations on IKE extensions (2 slides) was skipped because we were
overtime.
Next step:
- AS/PS to IESG after the meeting.
- WGLC soon for Core.
- Please read and commenst connexion latching then we WGLC it.
- Please read API docs so that we can adopt them as WG items.
- Please also read and comment short IKE extension draft.
That's it.
---------------------------------------------------------------------------
End of the meeting.
---------------------------------------------------------------------------
Attached are the preliminary minutes of the BTNS
session at IETF68. Please send corrections/additions
to the mailing list before 2007-04-09 (next Monday).
-- Julien & Love
BTNS Chairs
-------------- next part --------------
---------------------------------------------------------------------------
BTNS working group meeting minutes
---------------------------------------------------------------------------
These are the minutes for the Better than nothing security (BTNS) working group
meeting, held at IETF-67 on Wednesday, Mar 21, 2007, in beautiful Prague, Czech
Republik. Thanks to the people who have implemented MP3 recording of the
session on which these minutes are based.
Chair: Julien Laganier <julien.ietf at laposte.net>
(Love Hornquist Astrand excused)
Responsible AD: Sam Hartman <hartmans-ietf at mit.edu>
* Agenda
Preliminaries - Chairs
Core and Connection Latching - Nico Williams
<http://www.ietf.org/internet-drafts/draft-ietf-btns-core-02.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-01.txt>
API - Michael Richardson & Miika Komu
<http://www.ietf.org/internet-drafts/draft-komu-btns-api-01.txt>
<http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq-01.txt>
<http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-c-api-00.txt>
IKE Extensions - Michael Richardson
<http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ikeextensions-00.txt>
* Action items
- Chair to submit AS/PS to IESG for publication as Informational RFC
- Chair to issue WG Last call on BTNS Core document after meeting
- WG participants to read and comment connexion latching, API and IKE
extensions documents
* Narrative minutes for the session
---------------------------------------------------------------------------
Status update (Chair)
---------------------------------------------------------------------------
Missing couple of milestones, but chair confident that we can meet them soon.
AS/PS to IESG after the meeting.
Soon WGLC for core & connextion latching.
Soon adopt API documents as WG items.
---------------------------------------------------------------------------
Core BTNS (Nico Williams)
---------------------------------------------------------------------------
Slide 2: Change since -01
-------------------------
There's only two changes.
One was the changes made to the PAD SPD entries in the examples to remove
inconsistencies that Steven Kent pointed out. It's done, Steve can confirm.
I also reworded the bit about address accumulation. If you remember, we need
PAD entries to reject BTNS peers if their traffic selectors for their child SAs
could be asserted by non-BTNS peers. Better wording is to make two ordered
passes over PAD, one at authentication time, one at chid SA authorization time.
That's it for the changes.
Slide 3: Status: Ready for WGLC
-------------------------------
Status is I think it's ready for working group last call.
Questions?
I thought it was ready for working group last call modulo Steve comments,
so Julien I would ask for working group last call.
Actions: Chairs will issue WGLC.
--------
---------------------------------------------------------------------------
Connexion Latching (Nicolas Williams)
---------------------------------------------------------------------------
Slide 2: What
-------------
Connexion latching, it's sort of... It's to IPsec as TCP is to IP. It protects
packet flows coherently, not just packets. Kind of like TCP builds byte
streams out of packets. Alternatively it's a way to build IPsec channels.
It's needed because channel bindings needs IPsec channels.
In addition there's a desire to protect against change in
policy. Helps to address the problem where the PAD and SPD
policy allows multiple hosts to claim address from the same
networks Finally this is a fundation to IPsec APIs Questions:
Slide 3: Why
------------
We need it because you know for things like channel binding, we need IPsec
channels. In addition there is a desire to protect against a policy changing in
such a way that it will compromise packet flows. Also, it helps to address the
problem we discussed both in Montreal and I think in Vancouver, or wherever it
was, two meetings before, where you know, the PAD has an SPD policy basically
allowing multiple nodes to claim addresses from the same network making it
possible to steal each other's packets.
Finally, it's a foundation for IPsec APIs, and it's also sort of described
in terms of ... IPsec APIs.
Slide 4: How
------------
The idea is that when a connexion creation trigger occurs... in UDP you may
still have something like a packet flow, but it's not a connexion, think of
connected UDP sockets in BSD socket API... So what you do is that you figure
out what the peer ID is, and what kind of SA protection, ESP, whatever, what are
the algorithms, etc., and make sure that all subsequent packets for that packet
flow are protected by similar SA.
If you find packet from same packet flow which isn't protected, you drop. If
you want to send packet but don't have an SA, you drop.
On connexion tear down, you tear down the latch.
Slide 5: How
------------
The draft sketches two implementation designs, you don't have to do it in
either of these ways.
In approach #1, you record latch in upper layer protocol TCB, communicate
incoming/outgoing packet SA parameters between IPsec layer and ULP, effectively
tags packets as they move up/down in the stack
In datagram-oriented applications the latch would have to... Well, in
datagram-oriented applications, if the user connected socket, UDP socket, they
have to enforce latch.
Then in approach #2, you record the latch in the PAD and SPD and enforce the
latch at the IPsec policy layer.
Slide 6: Approach #1: Intimate Interfaces
-----------------------------------------
So approach #1 is the intimate interfaces, it effectively involves having
interfaces between the ULP and IPsec, and you know, we need a mean to say, hey
tell me how you protected this outgoing packet, and this incoming
packet was protected like so, and protect this packets like so.
Slide 7: Approach #2: PAD-based latching
----------------------------------------
PAD-based latching is a little more complicated, it basically requires ULP to
create create template PAD entry. For listeners we create 3-tuple template PAD
entry. For initiators we create 5-tuple PAD entry
Packets that match a template PAD entry cause an actual PAD entry to be
created. The child SA constraints are populated from the packet. The peer ID
populated from the SA that protected the incoming packet.
And on connection tear-down you have to remove the cloned PAD entry.
Slide 8: Properties
-------------------
Approach #1 works for connection-oriented and
non-connection-oriented ULPs. For UDP applications can connect UDP sockets, or
they can record and enforce the latch through ptokens, which is something we'll
see in Michael's presentation, or sendmsg/recvmsg.
The approach #2 also allows for UDP, but only in connected state. Approach #2
also needs a TIME_WAIT like state. This is because the tear-down of the flow
and latch have to be atomic with respect to new flow triggers. The wait time is
given by local latencies only, how long it takes for packets to move up and down
in the stack.
Slide 9: Properties
-------------------
But of course approach #2 is very close to RFC4301 model and if you have a NIC
that say provides ESP/AH/SPD offload but which don't provide a way to tag
packets, then you need to do something like approach #2.
Slide 10: APIs
--------------
At it's simplest this is just the traditional connect()/accept() BSD
socket-type APIs and they can work connection latching without the application
even knowing.
Slide 11: APIs
--------------
But IPsec APIs can give applications much more power. Who am I really talking
to, what is their IPsec ID, not their IP address but what is their certificate,
or what IP did they assert. Specify/verify that a connection's QoP meet/meet.
We can check whether the latch is ESP, AH, algorithms... We can do
leap-of-faith if we know the peer public key, and so on. So you see this in
Michael's and Miika's presentations and their I-Ds.
Slide 12: BYPASS OR PROTECT
---------------------------
Finally there's something that I don't know if it belongs to this draft or not.
It's BYPASS or PROTECT. Basically for some things it would be nice if you
could have the notion of optional IPsec protection so the example that I give
there is BYPASS
If you want to be able to leverage IPsec, you want to say hey if you can, give
me IPsec, and give me channel bindings, and we'll do channel bindings with the
RPCSEC_GESS layer.
Well if you can't do IPsec....
If we can negotiate this use of IPsec, great, so I call this BYPASS OR PROTECT.
In Approach #1 this is handled by the ULP or the application, you still need some
sort of SPD entry that says BYPASS OR PROTECT and the application knows what to do.
In Approach #2 this requires the same sort of things and some more.
Slide 13: BYPASS OR PROTECT
---------------------------
So in approach #1, the ULP and application is responsible.
In approach #2, we need to have some sort of template SPD entry, and that works
kind of like the template PAD entry that I described earlier. When a matching
packet arrives, unprotected, clone a BYPASS entry for just that 5-tuple. When
a matching packet arrives protected clone a PROTECT entry for just that
5-tuple. The ULP has to tear these down when the flows end. On outgoing flow
initiating packets the application must tell the system what it wants really,
and it must be able to do with IKE timeouts. So okay I'm not getting an IPsec
protection, so I just close that socket.
Slide 14: BYPASS OR PROTECT
---------------------------
So this is the example I gave before.
That's it.
Questions: I should point out that there are implementation of connexion
latching today, and some minimal set of APIs. If you use Solaris you can look
at the man pages for ipsecconf(1M) that describes connexion latching and tells
you that if you change policy your changes won't affect existing latching.
And then the ipsec(7P) man page tells you what socket option you can use to
request or check what algorithms are used, but you don't get to see what peer
identities are used so it's a small primitive API. I think KAME also has an
implementation although I'm not sure.
Questions:
----------
Chair: Who read the draft?
-> Two persons.
Chair: Please read the draft and comment on the mailing list.
---------------------------------------------------------------------------
C-Bindings for BTNS APIs (Miika Komu)
---------------------------------------------------------------------------
Slide 1:
--------
Hi everybody, My name is Miika Komu and I'll present work i did with
Sasu Tarkoma, Nicolas Williams and Michael Richardson.
Slide 2: What Problem Are We Solving?
-------------------------------------
So the problem that we are solving in practice is how do we make application
IPsec awarer. How can an application know that a connection is secured by
IPsec? How can the application tell to use the BTNS extensions. How to do
this using the C language with the socket API.
Slide 3: Diagram
----------------
We are interested in two kind of applications, the ones that use only the
IPsec API, and then application that also use TLS, GSS or SASL APIs.
Slide 4: Relationship to GSS/SASL
---------------------------------
So what's the difference then with these higher layer APIs, GSS and SASL. The
fundamental difference is that they are not using socket descriptors. The IPsec
API is tightly bound to socket descriptors, and can be used simultaneously with
GSS and SASL.
Slide 5: Policies
-----------------
Here are the functions for handling policies. There are some accessors to
create and get policies...
Slide 6: Channel Bindings
-------------------------
... and the same for channel bindings.
Slide 7: Changelog from 00 to 01
--------------------------------
And this is the changelog from 00 to 01... These are the old slides, I submitted
new ones, but never mind. 00 only contained ideas, but now there's some
concrete interfaces in the draft. Nico, Michael, Love and Julien have given me
lots of feebdack.
Slide 8: Todo list 1/3
----------------------
Todo list is quite long, so anyway it means some more code examples, and
definition of error values.
Slide 9: Todo list 2/3
----------------------
I'll fix the terminology in next version, the constants will be strings...
Slide 10: Todo list 3/3
-----------------------
Comparison functions for attributes to see if one protection is stronger than
another, but I am not sure it is needed. Then more attributes definitions, and
also conversion fucntions so that we can get human readable. Also lot of
editorial corrections.
These were actually the minimal version of the slides, I submitted longer slides.
Questions:
----------
Sam Hartman: You should submit slides you actually presented during the
session. Please make sure you don't overwrite these with newest version.
Chair: I'll send a link to the updated slides to the list, but proceedings will
contained presented version.
Chair: How many people read the draft?
-> Not too many
Sam Hartman: One thing would be to encourage reviewer to make sure that
anything in this API is consistent with RFC4301.
Michael Richardson: Sam when you say everything should be consistent with 4301,
there are three interpretations I can take with that. Which is that a 4301
implementation, all 4301 implementation implement everything in here? Or that
everything in here can be done by some subset of 4301? Or in fact does not
contradict with 4301 but may in fact extend it so that strictly 4301
implementation may need to be extended to implement this specification?
Sam: I propose that any... so first one, must not contradict 4301, that's
clearly important that you know for example you should not be able to... so for
example 4301 doesn't permit an implementation to... 4301 does not really have a
concept of optional encryption like... I mean things like connexion latching,
today I cannot say that it's okay for some people on application 1234 to use ESP
and for some people it's okay not to use it. I can't express that.
Michael: Right, that would be an extension.
Sam: That would be an extension.
Nico: But extensions are okay?
Sam: No... Okay, Steve is actually going to argue that this is not an
extension, Steve is going to argue that this is a fundamental change. So
certainly no fundamental changes, and we can have debates about what they are,
but I think Steve is going to be pretty firm on that one, that particular one.
Another thing is that, it would be nice if there were no... I would say that
extensions that are not covered by 4301 would be bad... for example 4301 ...
like SPD selection functions, and so if you wanted ... that would be fine, if
you wanted things that are beyond 4301 I don't think they should be specified
here, they should be specified as part of another document. Things in 4301
should be sufficient to implement API.
Nico: I don't know, why?
Sam: I don't think...
Michael Richardson: But the whole point of this whole effort is that people
want to do things that they can't do with just 4301. The whole point is that
we're trying to make applications that want to do things beyond that able to do
things. So limited to what 4301 says you can do, which does not say anything
about API, so we can't have an API with that argument. So clearly that's not
what you mean. The biggest issue is how do you interface there, and actually
Nico has addressed that in details in his draft on connexion latching, how do
you implement things, and actually there's one version of how do you implement
things that makes it much more difficult to do the things but it's possible to
do that with BITW or BITS implementation using relatively stricts 4301
concepts, although they may need the PROTECT OR BYPASS concept to be able to
cope with that. So with the additional, with the internet connexions to the
upper layer protocols we actually don't need or want to really go through all
of the 4301 mechanisms, we don't have to because we did a classification by
virtue of the fact that, particurlarly in the downward direction, by virtue of
the fact that we created the packet with knowledge of the SA we want to go in,
and that's pretty much it , and we also know in the TCP sockets which SA
specifically was supposed to be received on. So we actually don't need to go
and look at what the actual values were and Steve Bellovin has argued that
actually it's completely irrelevant what they are, what matters is the crypto
check determining whether the packet should be accepted by TCP. To not check
is an extension, but we don't need to say whether or not you go with that
effort so some of the rules in the processing instructions can be implicitely
skipped and there's some interesting advantages in doing that but functionally,
the functions are still there because TCP rejects packets from non originating
destinations anyway. So that's the question when you say, is it consistent with
4301, well we're saying that we get the same result if you implement it that
way, but we're not saying we work forward identical.
Sam: Steve, I am correct that you object as much as I think to the PROTECT OR
BYPASS concept?
Steve Kent: When we set up the working group initially we did had a long
discussion on important features of providing BTNS functionality. An essential
feature was to not undermine the access control functionality of an end system
doing simultaneously BTNS and conventional IPsec protection, so I think the
burden is on people writing these documents to explain how that is still
satisfied, rather than you know picking an individual issue here, it's to show
that when the thing is set-up, the criteria is still met.
Nico: Ok. And I think nothing in connexion latching undermines access control.
So connexion latching can be done without any API, sure. BYPASS OR PROTECT is
not needed if you do connexion latching without any API. However there is a
class of applications which today do one thing and which might do something
different if they could use IPsec. They might be able to say "hey, can we get
IPsec?" and if not let's do not IPsec. That's the only place where BYPASS OR
PROTECT comes in. And that would be done using port selectors that narrow
packet flows significantly only to these applications that know how to handle
this. Therefore I think no access control feature of 4301 model would be
violated.
Sam: Ok what Steve said today is much broader that what he said last time. I
think Steve... there is ... so ... I don't think that the API document should
be defining extensions to IPsec, I think that those should be somewhere else
and that the API document should be defining an API to use extensions that are
defined elsewhere. I am asking for architectural cleanliness
Nico: This particular extension is something that connexion latching...
Sam: I am not talking about connexion latching.
Nico: No, BYPASS OR PROTECT I guess?
Sam: No, I'm talking about the API document.
Nico: Ok, the API document does not specify extensions.
Michael: Well if we continue, my talk will try to show another direction, and it
will probably get more clear where we're going. We should actually have done
the talks in the reverse order.
Nico: Right because Michael's API is the abstract API, not the C API.
Chair: So maybe Michael you present the abstract API now...
Michael: Yes.
---------------------------------------------------------------------------
BTNS API proposal overview (Michael Richardson)
---------------------------------------------------------------------------
Actually I should but Bill Sommerfeld's name on these slides too.
But I'm not so sure if he's still alive, I've heard he is but couldn't talk to
him.
Slide 1: Three objects
----------------------
Oh yeah, these are also not the last version.
So, on Monday Nico convinced me to add this third bullet, on Tuesday he
convinced me to remove it. So essentially we have two objects and we concluded
that the third object was not a first class object but was rather an attribute
of the second object. We have protection Token, that deals with the details of
one session, so if you like you can link it to an IPsec SA. We don't really
want to tell that the application knows too many details of that, but that's
the kind of thing, they are specific to an SA, protection tokens have no scope
outside of the process you're running in, don't expect to put them in a Jabber
channel and have someone else knows what they mean or anything like that. So
they're very very specific, they have some attributes, some of these attributes
could be things like strength and key size and things like that. Absolutelly
never the actual keys, they would never be revealled. And anyone who did that I
think deserved to be slapped.
Then we have identity tokens, identity tokens are... I take a protection
token, you can get from that an identity token. An identity token somehow maps
to something like a certificate or other type of things, and may have what
we created what this crededntials token, and this is the notion that may tell
you where to get your private key, specifically in the case where they might be
offline, or in a kind of smartcard or something like that.
Slide 2: Connected sockets
--------------------------
So let's just talk about you how get things, and this maps a little bit to the
details like the C-bindings that Miika has worked on.
So let's talk first of a connected sockets, so TCP, SCTP, or UDP sockets that
call connect(), so basically we're not going to change I/O operations basis.
Initiator for these things is the end that calls connect(), and we suggest for
simplicity and describing the whole situation that you also think of it as such
because it called connect(), it also created the first packet, and therefore
caused IKE to do something and create the IPsec SA. Clearly that connexion
doesn't have to be here but it will make things much simpler for everyone to
understand.
The acceptor is the end that calls accept(), and therefore becomes the IKE
responder, and it's the IKE responder before the accept() call terminates so
this is important because the responder really doesn't know its policies until
after it gots the connexion, and the initiator of course would like to express
its policies before the connexion occurs, but it may actually not know the details
until after it completes, ok?
Slide 3: Use case #1
--------------------
So use case #1, call connect() as an initiator, and accept() as an acceptor,
and you didn't say anything special, and you say okay get my protection token
from the file descriptor that I got from this process, so in accept that's a
brand new file descriptor connected. Then you say okay get my iToken from the
pToken, and this tells me essentialy, from the cryptographic point of view, who
I am connected to. And if I like I can take a channel binding out of that, feed
it into my GSS API, connexion latching, do things like that, ah excuse me, into
the channel binding and I'm pretty much set ok? This assumes that the reason
why the system to setup an IPsec tunnel was determined by the system somehow,
so there is PAD entry, an SPD entry that said, when you talk to this host or
when you speak to this protocol or any number of various selectors that we have
in the system, said I want to do IPsec for this connexion, so no contradiction
no new things here, just IPsec occured for some reasons beyond the
application's knowledge and the application now can find out that in fact it
did happened. This case does not distinguish between the case where it might
happened, like BYPASS OR PROTECT, we don't know the situation we don't know
that there may ever be cases where it's not accepted. But if didn't go through,
we didn't have IPsec, we'll find out at one of these two points that there was
no IPsec there.
Slide 4: Use case #2
--------------------
So use case 2 is initiator, so you said get me the identity of my remote guy
bob with whom I wanted to talk to, and get a protection token, and this should
be essentially use my default identity whatever that is, I'm not going to tell
you, you figure out, you know, who I want to talk to, that's bob identity. At
a high level that might be a DN, that might be a raw public key, that might be
an IPsec address, or something else. At this level of the abstract API we're
not really going to care about that.
I have a file descriptor, I got it from my socket call, it's a newborn, I set
my protection token on this. What does that mean at the bottom level? That means
probably some kind of a template PAD entry goes into place, probably something
that has everything relatively well specified except for the originating ports.
Maybe it's a populate-from-packet...
Sam: You mean SPD entry?
Michael: Yeah I mean SPD entry, I'm sorry. And it calls connect(), and crypto
happens.
Acceptor is like use case 1, if you like... that call the connect call...
Nico: It's actually a template PAD entry as I described in the connexion latching
presentation, because we're saying we're trying to constrain the address in the
selector for the child SA for this packet flow for what happened to a protected
perr, and that happende in the back
Sam: And in the SPD?
Nico: And in the SPD, but specifically it happened in the PAD...
Michael: That's why I wrote in my notes SPD/PAD, and I didn't really sort out
what these things really are in my head, I just noted that I have a template
that means the right thing.
Emphasis that these are standard unpriviliged calls, there's some details as to
what extent an unpriviliged application can override the system, that's to a
system level setting to decide, that's well into the realm of local policy, and
you should think about it, and take ... but I don't think this is a subject for
standardization or really great discussion here, except to realize that's
considerations that you will have to make.
Sam: I disagree, I think that we actually do need needs to get in this space
so that we can provide IPsec solutions for the protocols we standardize and people
can understand how they interact with locally configured SPD entries, and that's
something I talk a little bit about last week-end, and talked off-line to some
people.
Michael: So Sam, are you suggesting that we should have in our API a statement
explaining under what circumstances an unpriviliged appplication may overrides
a system policy?
Sam: I am saying that use of IPsec 4301 should talk about how SPD entries from
applications are combined with system SPD entries, and what ordering would be
used. Not in your document, but in use IPsec 4301.
Nico: But it is in IESG right now?
Sam: No just use IPsec 4301. You said IPsec 4301... It's out of scope of your
document
Michael: I understand your concern and I agree there's a concern and if you feel
there need to be a greater statement I would be doing that.
Sam: I think it's out of scope of your document.
Michael: Yes.
Slide 5: Use case #3
--------------------
So this is initiator only, I say: I like to talk to Bob. And I say:
By the way, on this multi-user system, my name is Alice (Francis or Julie).
Furthermore, and this becomes different than in the other slide, somehow I have
this magic PKCS11 session.
Nico: It doesn't need to be PKCS11.
Michael: Yeah, this is not the point, the point is that there's a real world
example where you've logged into your desktop, your computer is remote but your
crypto identity is actually local to you and the application can somehow access
to it, and furthermore can tell the IKE how to talk to it. So that's the
important part of it, that somehow this handle, it's like a file descriptor,
that somehow you tell IKE use that identity, and the resaon why I say I'm
Alice, that's because these are definitely the phase 1 ids that ared use in the
parent SA. So now I can do the right thing. I get a protection token and I tell
the system I want to use these things as part of it. I set the token on the file
descriptor and call connect(). So then the identity and the credentials are
determined by the application not the system.
Slide 6: Use case #4
--------------------
This is on the other side, on the Bob side. Bob has said "I want to tell the
guy I'm Bob", and on this socket when you respond you need to make sure that
you set identity, so you set that on the file descriptor, we call accept, and
afterwards you probably want to find out who connected to you, and do
something. But of course you have to set your identity to respond with.
Potentially there's an https problem here, where you can only have an identity
per port 443 - IP address combination, because the crypto happens before the
virtual host thing. There's no good solution to that, there were proposals some
time ago to have the iniator say which responder they wanted to talk to. But in
this case the issue is that they don't say I want to talk to Bob, I said I am
Bob. I am unclear what happens. Maybe this is not a problem that we need to
solve, just need to write the question. They connected to me they said they
wanted to talk to Frank, but only Bob is listening. What does it connect to?
are we allowed to have multiple listening on the same port number with
different security associations? That's an interesting system question that you
might ask.
Sam: So, what is the purpose of Bob saying who he wants to be to accept?
Michael: Well, listening to any application where there's a secondary data
port like FTP, you may have a situation where control connection has Alice
to Bob, and later on you open a data port for them to connect back again,
so you're trying to express that on that port to listen on you don't want the
system identity, but Bob's identity.
Sam: Ok, but in the case where you are not the initiator...
Nico: I have an answer, in practice this is odd because when somebody comes to
you as a responder, they don't tell you right the way who they want, what
selectors they're using.
Michael: Right, but from an IKE point of view, you hope to discover the mismatch.
Nico: Well but the only thing that really does is act as a fallback. And we
could get rid of it because the application can always do the filtering itself.
And we could also have a notification from IKE that said: Oh dude you really
meant Bob.
Sam: Actually I disagree, I think that's kind of the wrong way to deal with this.
I think that what this is.. It serves two purposes, first of all, it says make
this identity available, if people try to establish an IKE SA to Frances then
let's do that. The second thing it does is it should if it turns out that you
need to establish an SA in the reverse direction then it says who to use as your
initiator identity. I don't think it makes sense to make this peer filter on
one responder identity it already accepted. If you want that kind of filter, it
should be on initiator side. And Initiator can do that and say : I want to talk
to Bob. And if it can't get Bob, then that connect() fails.
Slide 7: Unconnected sockets (datagrams)
----------------------------------------
The next discussion is for unconnected sockets. You should think of this a
little bit as this is the interface between TCP connected systems and lower
layers.
Slide 8: Use case #5
--------------------
The protection, the people you're talking to can change on every packets. So
you can't just get the data independently of the packet. You can't use read()
or fread() calls to get this stuff out. You could get the identity out and
protection token on every packet you receive, so somehow you have to get it out
of the recvmsg() call, so I put it there but in reality it would come through
ancillary data. So you get that each time, itoken, ptoken, and in this case the
initiator identiy and credentail determined by the system. It's not clear for
unconnected if you can really set who I am expecting to be before I connect to
you. And you could do that again it would probably work. So you could set your
Bob identity.
Slide 9: Use case #6
--------------------
For the initiator you get protection token and you send the message with the
protection token. Now that may be a template ptoken. We don't think that
there's any guarantee that you could use the ancillary data cmsg as a value
result parameter. So you put the ptoken in, we're not sure how to get the
ptoken out again, the one that actually was used, the one that contains the
parameter of the session that was actually created as that message was sent.
Including non-templated PAD/SPD parts. So it's an open question how to do that
for this. I think that a number of systems could just happily do it, but I
don't think it's guaranteed by any spec we have. Again unprivileged calls.
Slide 10: Similarities to GSSAPI
--------------------------------
We intentionaly did this similar to GSSAPI. And in GSSAPI the ctoken has to be
first class object because there's no other context to associate with, because
GSSAPI just lives in whatever kind of bytestream. Use case 5 and 6 are not
easily implemented for systems using connection-latching section 2.2 "Latching
through PAD manipulations and extensions". If you are using "Intimate
interfaces between ULPs and IPsec" this is really easy to do, I actually
implemented it a year ago, for not actually for connected sockets, for
unconnected sockets where you cannot use any kind of standard selectors because
the host at the other end with the transport mode SA to .... The document that
I wrote should become the abstract API, and Miika's document should become the
C-bindings of the abstract API. This is fairly similar to the way GSSAPI did
it. Nico told me to my surprise that the GSSAPI documents were actually
standard track, not informational. We should ask the audience what do you
think? Any objection to the approach?
Sam: I think the abstract API presentation was very useful, we can solve
issues with 4301, I think this is a very good model. I think it's not
completely abstract...
Michael: I wanted to say is that the only thing you get to is the socket,
kernel is in charge of rest of the details.
Sam: I think it's a very good thing.
---------------------------------------------------------------------------
Wrap up (Chair)
---------------------------------------------------------------------------
Last presentations on IKE extensions (2 slides) was skipped because we were
overtime.
Next step:
- AS/PS to IESG after the meeting.
- WGLC soon for Core.
- Please read and commenst connexion latching then we WGLC it.
- Please read API docs so that we can adopt them as WG items.
- Please also read and comment short IKE extension draft.
That's it.
---------------------------------------------------------------------------
End of the meeting.
---------------------------------------------------------------------------