[11:47:10] --- Simon Josefsson has joined
[13:52:06] --- Jim has joined
[13:55:05] --- kdz has joined
[13:55:15] --- hartmans has joined
[13:55:20] --- kdz has left
[13:57:31] --- warlord has joined
[13:59:08] * warlord has set the topic to: The Security Area Advisory Group
[14:00:08] --- raeburn has joined
[14:00:57] --- tlyu has joined
[14:03:09] --- lha has joined
[14:03:35] --- marcos.sanz has joined
[14:03:38] --- shep has joined
[14:05:05] <warlord> SAAG Agenda
[14:05:15] --- lha has left
[14:05:18] <warlord> WG reports, BOF Reports, Invited Presentations, Open Mic
[14:05:31] <hartmans> For Paul's benefit, all the slides are available. However since he's here this time, it doesn't matter as much to him.:-)
[14:05:54] <warlord> Is there anyone in this jabber room who isn't in Dallas?
[14:05:54] --- lha has joined
[14:06:10] <Simon Josefsson> warlord: me. I'm listening to audio though.
[14:06:35] <warlord> Okay. then I wont scribe here.
[14:06:52] --- utashiro has joined
[14:09:26] --- hallam has joined
[14:10:09] --- mjo has joined
[14:10:35] --- gurtov has joined
[14:10:45] --- gmarzot has joined
[14:11:15] --- jhutz has joined
[14:11:55] <lha> Hi, I'm Love Hörnquist Åstrand and I'm chairing BTNS together withPekka Nikander. The BTNS working group had its third meeting as aworking group monday morning.Three documents where discussed during the meeting, the "Problem andApplicability Statement", "An Unauthenticated Mode of IPsec", and"IPsec Channels: Connection Latching", the two later accepted asworking group document since the last meeting."Problem and Applicability Statement" have a couple of outstandissues, and will hopefully go to working group last call after nextrevision. The draft should be submitted in May.We also had a presentation of Nicolas Williams drafts "AnUnauthenticated Mode of IPsec" and "IPsec Channels: ConnectionLatching". The group thought that direction of document was the rightone. There was consensus that the document was too tense, and thatNicolas needed fill in more details how it should work and how itwould fit into IPsec processing.There was a discussion on how to proceed with the API item that oncharter for the working group. Sam Hartman, with help from DavidBlack, will present at next IETF. Michael Richardson promised to lookat the old API requirements document that he and Bill Sommerfeld madefor IPSP.
[14:13:44] <raeburn> "Tense"? "Terse", I think
[14:13:44] --- Jim has left: Lost connection
[14:16:02] --- jis has joined
[14:17:06] --- robsiemb has joined
[14:17:06] --- raeburn has left: Disconnected
[14:19:25] --- lha has left
[14:19:39] --- robsiemb has left
[14:20:34] --- kurosaki has joined
[14:21:13] --- shima has joined
[14:21:36] --- dumdidum has joined
[14:21:47] --- tonyhansen has joined
[14:21:54] --- kdz has joined
[14:22:18] --- kdz has left
[14:22:23] --- kdz has joined
[14:22:42] --- jimsch1 has joined
[14:23:03] --- shima2 has joined
[14:23:08] --- robsiemb has joined
[14:24:08] --- kmurchison has joined
[14:25:24] --- psavola has joined
[14:26:15] --- fenton has joined
[14:26:45] --- eludom has joined
[14:28:12] --- Jim has joined
[14:28:47] --- raeburn has joined
[14:29:39] --- Barry Leiba has joined
[14:30:10] <eludom> is anybody jabber scribbing ?
[14:30:11] --- shima2 has left: Replaced by new connection
[14:30:12] --- shima2 has joined
[14:30:28] --- shima has left: Replaced by new connection
[14:30:34] --- raeburn has left: Replaced by new connection
[14:30:37] --- robsiemb has left
[14:30:38] --- raeburn has joined
[14:31:05] <jhutz> No, no one is scribing. We are in WG repotrs at the moment.
[14:31:11] <fenton> eludom: warlord decided not to, because the only remote participant is listening to audio.
[14:31:12] <warlord> eludom: no, because everyone at the time was either in the room, or listening to audio
[14:31:21] <jhutz> There is audio, and I'm told the slides for the presentations are online already.
[14:31:56] * warlord is paying attention here for people to make comments /from/ jabber..
[14:32:51] --- raeburn has left: Replaced by new connection
[14:34:00] --- ShoichiSakane has joined
[14:34:53] <jhutz> audio at :http://videolab.uoregon.edu/events/ietf/ietf654.m3u
[14:35:57] --- marcos.sanz has left
[14:36:09] --- marcos.sanz has joined
[14:42:08] <jhutz> slides at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65#wg-saag
[14:45:23] --- stephenfarr has joined
[14:47:58] --- kmurchison has left
[14:49:33] --- doug_trendmicro@jabber.org has joined
[14:49:36] --- raeburn has joined
[14:49:40] --- gmarzot has left: Lost connection
[14:53:14] --- jlcjohn has joined
[14:53:58] --- utashiro has left
[14:55:52] --- Jeffrey Altman has joined
[14:56:02] --- gregory has joined
[14:56:44] --- ogud has joined
[14:57:35] --- utashiro has joined
[14:57:48] <Jeffrey Altman> what presentation is being given at the moment?
[14:58:07] <raeburn> capwap
[14:58:07] <warlord> CAPWAP
[14:59:16] <jlcjohn> (It would help folks with audio only if there were notes which slide is up...)
[14:59:34] <gregory> can someone channel me, Gregory Lebovitz, Juniper:
[14:59:35] <gregory> "how realistic is it that deployers will actually use multi-vendor? We originally thought that we needed to standardize management for IPsec, but in the end, people only deployed (mostly) single vendor. So will this be the same?"
[14:59:40] --- john.levine has joined
[14:59:53] <gregory> BTW, I'm on the audio.
[15:00:09] --- doug_trendmicro@jabber.org has left
[15:00:27] --- gurtov has left
[15:00:54] <gregory> thx
[15:01:38] --- kivinen has joined
[15:01:41] --- alexeymelnikov has joined
[15:01:57] <raeburn> Ron Bonica, Authentication for TCP-based Routing and Management Protocols
[15:03:11] --- raeburn has left: Disconnected
[15:03:25] --- kdz has left
[15:05:02] --- raeburn has joined
[15:05:45] --- raeburn89686 has joined
[15:06:35] --- raeburn has left
[15:08:34] --- fenton has left: Replaced by new connection
[15:10:45] <hartmans> Ekr: I think that employee leaving is sufficient justification for key ids.
[15:10:50] <hartmans> I'm not sure about the whole time window thing
[15:13:15] <warlord> I still don't think you need 64 keys, tho.
[15:14:57] <shep> Yeah, 32 would be enough I think, so one bit could be saved in the header. :-)
[15:15:55] <gregory> i would very much like to see if we couldn't figure out how to solve this problem with IKE/IPsec.
[15:16:03] <gregory> It seems to me a much easier problem to solve...
[15:16:22] <gregory> to address the CONs on IKE/IPsec than to create a new TCP security/auth protocol.
[15:16:52] <jhutz> Does this room lack a chair mic?
[15:17:05] <psavola> greg, you're not the only one in wondering about that :-)
[15:17:15] <gregory> Now I have to go, so I'll need to catch up on the audio and jabber archives later.
[15:17:45] --- Jim has left
[15:17:53] <gregory> but Ron and I have committed to talk later this month on the topic.
[15:18:21] <psavola> given that TCP-MD5 isn't really required in most cases in any case for careful ISPs (read: those that employ ingress filtering or equivalent technologies)
[15:19:23] --- fenton has joined
[15:19:33] <gregory> Pekka, perhaps you should write (or point to existing) I-D/RFC/BCP on the filtering and why you think it negates need for crypto-auth'd BGP conn's.
[15:20:26] --- john.levine has left
[15:20:29] <psavola> A draft will be coming out soon...
[15:21:32] <gregory> Russ, if we decide we need to create an authentication method for TCP, should that be done in Routing or in Security Area?
[15:22:10] <gregory> or that last comment can be directed to Russ/Sam
[15:22:58] <gregory> and, to Tero's point, you can create a loopback address and apply the IPsec to the loopback address.
[15:23:35] <hartmans> IT should be done in transport area where it is.
[15:24:49] --- utashiro has left
[15:25:00] <hartmans> Haven't we heard this part before?
[15:26:23] <jhutz> Probably. I think if we didn't believe in open standards already, we wouldn't be here.
[15:26:46] <jhutz> RFC4226 is _not_ a standard.
[15:26:48] --- abhayroy has joined
[15:27:23] <jhutz> But indeed, what he's talking about now is not what we heard about before.
[15:29:04] --- abhayroy has left
[15:29:48] --- abhayroy has joined
[15:30:14] --- ekr has joined
[15:30:14] --- abhayroy has left
[15:31:29] <ekr> I've got a question. What happens after the router reboots. It starts up connections in the same order with the same keys and the same local ports. But different sequence numbers. Now you have two parallel authenticated streams. With potentially overlapping sequence # spaces.
[15:31:36] <hartmans> Can someone ask about whether you can bind this to a crypto channel?
[15:31:49] --- abhayroy has joined
[15:33:50] --- abhayroy has left
[15:34:14] <jhutz> "You can't do anything else if you want to be really secure".
[15:34:15] <jhutz> False.
[15:36:19] <jhutz> In a high-value case, you might want to force the user to verify the server's identity by comparing a short number to what's displayed on a token instead of using something involving crypto?
[15:40:58] --- ekr has left
[15:41:28] <jhutz> He's not answering the question.
[15:41:45] <Jeffrey Altman> huh?
[15:42:08] <tlyu> they're evading the question about channel bindings and MITM mitigation
[15:42:14] <jhutz> Sam's question was "how can I bind this to a channel?"
[15:42:21] <jhutz> The answer was "you need a secure channel".
[15:42:37] <jhutz> Sam pointed out you can't _have_ a secure channel if you haven't bound it to the identity of at least one end.
[15:42:46] <jhutz> PHB then babbled about keystroke loggers.
[15:42:51] <hartmans> phb is making a good case for oath without mutual auth but I don't see how his point responds to my concern.
[15:43:09] <jhutz> Well, not babbled; he had a legitimate point. But I don't think it answers the question.
[15:44:01] <hallam> The point is that you need to look at the security of the particular use cases.
[15:44:38] <hartmans> Sure. But I don't see how challenging the server helps the phishing use case.
[15:45:07] <hallam> The phishing attacks involve malware, sometimes even hardware keyloggers
[15:45:07] <hallam> What the banks would like from OATH is a system that the users cannot screw up however hard they try
[15:45:29] <jhutz> If you have to trust the computer to establish a secure connection and authenticate the server, then challenging the server doesn't buy you anything.
[15:45:54] <jhutz> BTW, users can trivially screw up challenging the server, by not bothering to check the response against what the token says it should be.
[15:46:14] <hartmans> Phil, you're arguing for two-factor authentication. I think I get why providing a challenge from the server and response from the client is useful.
[15:46:17] --- shima2 has left: Replaced by new connection
[15:46:18] --- shima2 has joined
[15:46:37] <jhutz> If you want to challenge the server in a way the users can't screw up, you have to make the users type something from the server into the token and have the token do the checking.
[15:47:28] <hallam> There is a diference between 'does not buy you anything' and 'does not protect against all possible attacks'
[15:47:28] <hallam> If you are arguing that there should also be a single phase challenge response then OK, yes that should be in the spec, definitely as an option
[15:47:49] <jhutz> And if you want to protect against a phisher providing a URL to a bogus server, then you have to protect against the case where the bogus server connects to the real one and tunnels the challenge/response, then punts the user and does whatever they want, or punts the server and gets more data from the user, or both.
[15:48:16] <jhutz> You do _that_ by cryptographically binding the mutual auth to the channel.
[15:48:21] --- fenton has left
[15:48:42] <hartmans> This is an extension of a single phase version to a multi-phase version.
[15:48:43] <jhutz> "Does not buy you anything" in this case means "is neither necessary nor sufficient for security".
[15:48:59] <hartmans> I understand the single phase version in RFC 4226. That seems useful. I don't understand how this extension is useful.
[15:49:41] <jhutz> If you must trust the browser to verify the server's identity, then challenging the server is not necessary. If you cannot bind challenging the server to the channel, then challenging the server is not sufficient.
[15:50:04] <jhutz> I suggest we suspend this discussion to pay attention to the current talk, and pick it up again later.
[15:50:09] <hallam> In practice the typical bank is going to deploy these for two level security. So the challenge is only used to access the transaction level.
[15:50:09] <hallam> We are not relying on the crypto alone, we have active response
[15:51:53] --- mjo has left
[15:54:54] --- raeburn89686 has left
[15:55:08] --- raeburn has joined
[15:56:36] --- mankin has joined
[15:57:57] <jhutz> Is/will there be a new mandate wrt HMAC-MD5 ?
[15:58:20] --- Barry Leiba has left
[15:59:47] --- kurosaki has left
[16:00:59] --- jis has left: Logged out
[16:02:26] --- tlyu has left
[16:02:36] --- alexeymelnikov has left
[16:03:12] <jhutz> Stop over here after the session ends?
[16:03:17] <jhutz> Wrong room
[16:03:33] --- jimsch1 has left
[16:03:48] --- hartmans has left
[16:04:04] --- hallam has left
[16:04:37] --- psavola has left
[16:05:05] --- raeburn has left: Disconnected
[16:05:30] --- mankin has left
[16:05:34] --- dumdidum has left
[16:05:54] --- jhutz has left
[16:05:54] --- ShoichiSakane has left
[16:05:57] --- kivinen has left
[16:06:36] --- shep has left
[16:08:05] --- stephenfarr has left
[16:10:37] --- Simon Josefsson has left
[16:12:42] --- ogud has left
[16:13:15] --- warlord has left
[16:14:58] --- marcos.sanz has left
[16:15:36] --- shima2 has left: Replaced by new connection
[16:15:36] --- shima2 has joined
[16:18:10] --- Jeffrey Altman has left
[16:26:29] --- dumdidum has joined
[16:32:41] --- tonyhansen has left
[16:36:14] --- shima2 has left: Replaced by new connection
[16:36:14] --- shima2 has joined
[16:36:27] --- shima2 has left
[17:04:22] --- dumdidum has left: Replaced by new connection
[17:26:23] --- eludom has left
[17:33:45] --- ogud has joined
[17:39:01] --- gregory has left
[17:47:51] --- ogud has left
[18:45:05] --- jlcjohn has left
[19:31:21] --- shima has joined
[19:32:33] --- shima has left