[12:36:58] --- mrex has joined
[12:51:00] --- ryu.inada has joined
[12:51:45] --- psavola has joined
[12:59:11] --- sftcd has joined
[12:59:40] --- ekr has joined
[13:00:23] --- tlyu has joined
[13:01:32] --- weshardaker has joined
[13:02:36] --- leiba has joined
[13:02:38] --- marcos.sanz has joined
[13:02:38] --- eludom has joined
[13:02:48] --- kivinen has joined
[13:03:21] --- hartmans has joined
[13:03:26] <eludom> Call for scribe
[13:03:27] --- jhutz has joined
[13:03:33] --- fenton has joined
[13:03:34] <jhutz> scribes have been found.
[13:04:01] --- stefans has joined
[13:04:16] --- shep has joined
[13:04:19] --- dumdidum has joined
[13:05:12] <eludom> starting.
[13:05:24] --- ben@www.links.org has joined
[13:05:27] <eludom> agenda
[13:05:30] --- nico has joined
[13:05:35] --- ben@www.links.org has left
[13:05:40] * nico will scribe
[13:05:47] --- miaofy has joined
[13:05:54] --- ben has joined
[13:06:06] --- dcrocker has joined
[13:06:21] <eludom> WG reports
[13:06:26] <nico> krb wg
[13:06:33] <nico> had productive meeting on Monday
[13:06:40] <nico> have published PKINIT (cheers)
[13:06:49] <nico> published gss mech enc nego
[13:06:54] <nico> had two presentations
[13:06:57] <nico> one on OTP pre-auth
[13:07:10] <ekr> Is the detailed agenda available?
[13:07:24] <nico> one on a proposal for inter-kdc communication protocol to lighten load on feeble client devices
[13:07:31] <nico> ....
[13:07:34] <ekr> (The one on the web appears to be minimal....)
[13:07:34] <nico> missed some stuff
[13:07:47] <nico> kitten wg
[13:07:59] <nico> met on Monday afternoon
[13:08:16] <nico> we've published two docs describing the GSS PRF function and krb5 bindng
[13:08:27] <nico> we have seven docs that will go to WGLC in the next two months
[13:08:33] <nico> we updated the milestones
[13:08:35] --- kurosaki has joined
[13:08:45] <jhutz> Audio for this room will be available at http://videolab.uoregon.edu/events/ietf/ietf665.m3u
[13:08:46] <nico> technical discussion on gss naming for krb5 w/ anon princ support
[13:08:52] <nico> and gss naming extensions
[13:08:57] <nico> LTANS not here
[13:09:01] <nico> the chairs could not stay
[13:09:13] --- jimsch1 has joined
[13:09:24] <nico> their ERS doc will go to WGLC soon
[13:09:33] <nico> SASL met on Monday afternoon
[13:09:48] <nico> doc status: outstanding issues in CRAM-MD5, GS2, DIGEST-MD5
[13:10:00] <jhutz> Meeting summaries for all security area WG and BOF meetings have been or will be sent to the saag mailing list.
[13:10:01] <nico> the "GSSAPI" doc has been sent to the IESG
[13:10:14] <nico> DIGEST-MD5 issues with fast rea-auth
[13:10:16] --- danyork has joined
[13:10:31] <nico> had extensive discussion of channel bindings (see GS2) and TLS
[13:10:37] <nico> updated our milestones
[13:10:49] <nico> most things will go to last call in August
[13:10:50] --- vidya has joined
[13:10:55] --- tlr has joined
[13:11:10] <nico> sam: krb, kitten, sasl had experiment
[13:11:16] <nico> extra wireless mics
[13:11:28] --- richard.barnes has joined
[13:11:29] <nico> two projectors, one for presentations, one for jabber
[13:11:37] <nico> this seemed very useful/productive
[13:11:50] <nico> russ: I've asked for a summary of this to be sent to wg chairs list
[13:11:54] <nico> PKIX WG
[13:12:16] <nico> met once for two hours, including a joint session with SIDR WG
[13:12:25] <hartmans> Can someone give me the URL for the presentation tool?
[13:12:29] <hartmans> I.E. to upload slides
[13:12:34] <nico> IESG comments should be resolved this week
[13:12:46] <nico> discussion of OCSP alg agility
[13:13:11] <nico> stephan completed draft review for the CMC drafts
[13:13:19] <jhutz> I will send it momentarily
[13:13:23] <nico> will be sent to ADs
[13:13:27] <nico> SCVP ...
[13:13:30] <nico> missed that
[13:13:38] --- Dave Nelson has joined
[13:13:44] <nico> we've not yet initiated MIME types review
[13:13:53] <nico> (missing some stuff)
[13:13:55] <eludom> 3280bis wg last call
[13:14:05] <nico> ah
[13:14:15] <jhutz> Once Sam uploads the presentations, they'll be available online at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66#wg-saag
[13:14:21] <nico> issue with name types ranges that CAs must know how to do constraints for
[13:14:26] <nico> ...
[13:14:26] <eludom> presentation on algorithm use with ECC
[13:14:36] --- mrichardson has joined
[13:14:42] --- lha has joined
[13:14:57] <nico> proposal to make use of a fields in SAN
[13:15:09] <nico> ...
[13:15:16] <eludom> proposal adopted by ANSI...conflicts with the way we've done things
[13:15:22] <nico> yup
[13:15:45] --- Jeffrey Altman has joined
[13:15:48] <nico> consensus on creating distinct access method for use in attr certs
[13:15:59] <nico> an AC issuers method
[13:16:05] <nico> ...
[13:16:06] <nico> BTNS
[13:16:17] <nico> met on tuesday
[13:16:28] <nico> discussed applicaibility statement
[13:16:33] <nico> will WGLC in August
[13:16:41] <nico> discussed leap of faith
[13:16:48] <nico> we're not sure if that belongs here
[13:16:56] <nico> the core doc is progressing nicely
[13:17:16] <eludom> Starting to look at API
[13:17:22] <nico> there will probably be two documents, one on API & channel bindings, one on PAD/SPD API
[13:17:31] <nico> we had a discussion on overlap with SHIM6
[13:17:37] <nico> we concluded that there was none
[13:17:42] <nico> russ: do they agree
[13:17:50] <nico> love: we don't know yet
[13:17:51] <nico> ...
[13:17:54] <nico> will check
[13:17:56] <nico> TLS
[13:17:59] <nico> met on Tuesday
[13:18:06] <nico> details of PRF negotiation...
[13:18:13] <nico> TLS counter mode cipher suites
[13:18:21] <nico> OTP cipher suites presentation
[13:18:24] <nico> plenty of discussion
[13:18:33] <nico> in current state not secure enough to be a WG doc
[13:18:50] <nico> proposal for integrity protection only cipher suites
[13:18:57] <nico> ...
[13:19:01] <nico> (missed some stuff)
[13:19:11] <nico> running DTLS over SCTP
[13:19:24] <nico> Proposes to derive keys and move them to SCTP
[13:19:37] <nico> (huh? SCTP has crypto?)
[13:19:41] <nico> DKIM
[13:19:49] <nico> met twice on Tuesday and Wednesday
[13:19:58] <nico> asked for help from DNS about use of RRs
[13:19:59] <ekr> SCTP has this thing called SCTP-AUTH which is designed to stop injection attacks.
[13:20:03] <eludom> useing TXT records for keys
[13:20:04] --- sftcd has left
[13:20:06] <nico> they're not too happy, but moving on
[13:20:13] <nico> had an overview doc
[13:20:24] <nico> discussion of sender signing practices
[13:20:31] <nico> we're looking for input
[13:20:34] <eludom> looking for authors
[13:20:42] <nico> russ: you're not starting that until after SSP comes up
[13:20:47] <nico> no, yes we are
[13:20:48] <nico> ...
[13:20:51] --- fenton has left
[13:20:56] <nico> OpenPGP
[13:21:00] <nico> met on Tuesday
[13:21:04] <nico> had ten ppl in the room
[13:21:13] <nico> the 2440bis doc had been sent to Sam
[13:21:20] <nico> shut down WG?
[13:21:28] <nico> Sam asked how many reviewers
[13:21:40] <nico> if not enough, shut down
[13:21:44] <nico> checking on list
[13:21:49] --- sftcd has joined
[13:21:51] <nico> (missed stuff)
[13:21:53] <eludom> history of multiple sig doc
[13:22:02] <nico> talking about getting 2440bis to Draft Standard
[13:22:06] <nico> MSEC
[13:22:17] <nico> met in the last session on Tuesday
[13:22:24] <nico> making progress at a decent pace
[13:22:32] <nico> want to finish by San Diego
[13:22:41] <nico> one work item is IPsec extensions for MSEC
[13:22:46] <nico> work re-org
[13:22:50] <eludom> but some new work has come up...
[13:22:52] <nico> some stuff was pulled out
[13:23:00] <nico> ...
[13:23:12] --- mrex has left: Disconnected
[13:23:21] --- richard.barnes has left: Logged out
[13:23:25] <nico> this will help get review
[13:23:30] <nico> interop work going well
[13:23:43] <nico> composite groups
[13:23:51] <nico> a problem to be studied
[13:23:54] --- richard.barnes has joined
[13:24:02] <nico> checking if there will be enough ppl to work on that
[13:24:14] <nico> RMPs doc almost ready for WGLC
[13:24:21] <nico> sec cons text needed
[13:24:32] <nico> something about needing confdentiality protection
[13:24:45] <nico> issue being whether to re-use ESP or invent something new
[13:24:51] <eludom> Disucssion of writing new transport layer security protocol....quickly.
[13:24:53] <nico> they want to move quickly
[13:25:00] <nico> ...
[13:25:04] <nico> EMU
[13:25:13] <nico> met on Wednesday
[13:25:21] <nico> generalize pre-shared key method
[13:25:29] <nico> output of design team
[13:25:43] <nico> general consensus to take this on as WG item to meet charter item
[13:25:49] <nico> had discussion of cipher suites
[13:25:50] <nico> ...
[13:25:59] <nico> presentation of progress of EAP-TLS
[13:26:03] <nico> a few open issues
[13:26:08] <nico> a few things noted
[13:26:15] <nico> interop problems with 23DES cipher suites
[13:26:23] --- richard.barnes has left: Logged out
[13:26:24] <nico> several variants of EAP-TLS
[13:26:34] <nico> ...
[13:26:45] <nico> some discussion of identity privacy
[13:26:55] <nico> next topic was on other EAP/TLS related methods
[13:27:00] <nico> EAP-TLS-PSK
[13:27:12] <nico> identity privacy scheme was discussed also
[13:27:21] <nico> consensus was that TLW WG should discuss this
[13:27:31] --- richard.barnes has joined
[13:27:34] <nico> need more discussion on list to make progress
[13:27:46] --- jimsch1 has left
[13:27:48] <nico> presentation on implementing new EAP methods
[13:27:59] <nico> ...
[13:28:02] <nico> INCH
[13:28:20] <nico> last meeting, hopefully
[13:28:26] <nico> met on wednesday
[13:28:30] <nico> talked about interop
[13:28:40] <nico> what remains to bring our 5 docs to completion
[13:28:47] <eludom> WG last call on reqs
[13:28:52] <eludom> resulted in one more doc
[13:28:54] <nico> interop testing
[13:29:07] <nico> minor errors in optional/required fields
[13:29:15] <nico> got some new text on IANA
[13:29:28] <nico> transport, RID, phishing extensions ready for WGLC
[13:29:37] <nico> another interop will be held
[13:29:42] <nico> dealing with transport issues
[13:29:51] <nico> plan is to hold that the week before San Diego
[13:29:52] --- mrex has joined
[13:29:55] <nico> ISMS
[13:30:10] <nico> two WG docs are progressing
[13:30:30] <nico> consensus on clearly separating user authentication from ...
[13:30:37] --- mankin has joined
[13:30:48] <nico> had nteresting discusion on how to send notifications
[13:31:01] <nico> discussion on initiating ssh session in reverse mode
[13:31:12] <jhutz> I'm not sure if he was talking about authentication vs authorization, or authorization for access vs authorization for specific operations. both are active issues
[13:31:13] <nico> security concerns
[13:31:29] <nico> discussion on integrating our work with RADIUS
[13:31:35] <nico> some open issues to discuss
[13:31:46] --- bert has joined
[13:32:04] <nico> confusion between RADEXT and ISMS on RADIUS authorization-only mode
[13:32:24] <nico> ISMS rep to RADEXT was told by RADEXT that the proposal conflicts with Kerberos
[13:32:36] <nico> but the KRB WG chair at ISMS said the opposite
[13:32:42] <nico> how to resolve such issues
[13:32:45] <nico> ?
[13:32:59] --- Jelte has joined
[13:33:01] <nico> russ: get a couple of guys from krb and radext ...
[13:33:04] <nico> ^get^got^
[13:33:07] <nico> working on it
[13:33:14] <nico> ...
[13:33:19] <nico> S/MIME
[13:33:27] <nico> meeting *after* SAAG
[13:33:34] <nico> digest migration
[13:33:47] <nico> multiple signatures
[13:33:53] <nico> somethng on encryption schemes
[13:33:57] <nico> BoFs
[13:33:59] <nico> had two
[13:34:03] <nico> NEA Tuesday morning
[13:34:10] <nico> interop between NASs
[13:34:20] <nico> focus of discussion was on charter
[13:34:21] <eludom> good attendance
[13:34:22] <nico> use case
[13:34:23] <nico> scope
[13:34:38] <nico> were able to reach agreement on several issues
[13:34:45] <nico> mandatory to implement transport
[13:34:47] <nico> ...
[13:34:53] <eludom> reached agreement on manditory transport, vendor attributes, blind endpoints
[13:34:59] <nico> rough consensus on creation of WG
[13:35:18] <nico> the BoF chairs will work with ADs, list to work through charter issues
[13:35:24] <nico> HOAKEY BoF
[13:35:55] <nico> trying to do EAP NAS handover
[13:36:02] <nico> several proposals
[13:36:11] <nico> trying to figure out which direction to go in
[13:36:14] <nico> not much success
[13:36:27] <nico> trying to settle on reqs
[13:36:32] <nico> so we could bash out a charter
[13:36:55] <eludom> smb will try to put out proposed charter in next week
[13:36:58] <nico> will try to figure out the direction
[13:37:14] <eludom> strong agreement for a WG
[13:37:15] <nico> strong agreement that we want to have a WG in this space
[13:37:22] --- cat has joined
[13:37:34] --- ldondeti has joined
[13:38:09] --- Jim Galvin has joined
[13:38:28] --- weiler has joined
[13:38:37] * nico asked about one particular direction (pseudo-method), whether that would belong in EMU
[13:38:58] <nico> Sam answered: no, EMU is very tightly chartered, it will do nothing more than what it has on its plate
[13:39:04] <nico>
[13:39:11] <nico> Invited presentations
[13:39:13] --- gordon.lennox has joined
[13:39:24] <nico> first: why BGP and IPsec don't play well together
[13:39:27] --- Suzanne has joined
[13:39:32] <mrex> speak up, please
[13:39:53] <nico> noone's talking yet Martin
[13:40:00] <nico> :)
[13:40:07] --- mjo has joined
[13:40:11] <eludom> slides not on IETF site yet.
[13:40:12] <nico> Brian Weis is the presenter
[13:40:23] <nico> talk begins.... now
[13:40:30] <eludom> Brian Weis
[13:40:45] <nico> I work for a router vendor (quiet laughs)
[13:40:48] --- fenton has joined
[13:40:59] <nico> question comes up: why don't they use IPsec
[13:41:08] <nico> so, I've done some investigation...
[13:41:13] --- Jelte has left: Logged out
[13:41:24] <nico> first point: of course, it works
[13:41:43] <eludom> you should use it...if you are comfortable with it
[13:41:44] <nico> problem: operation considerations
[13:41:47] <eludom> big if
[13:41:52] <nico> re-key issues
[13:41:55] <nico> DoS issues
[13:42:01] <nico> slide 3
[13:42:15] <eludom> 3746 terminology
[13:42:43] <jhutz> network element (ne) - the whole router/whatever
[13:42:45] --- mankin has left
[13:42:53] <jhutz> forwarding element (fe) - blades containing ports
[13:43:02] <nico> jhutz: don't describe the slide!
[13:43:05] <nico> :)
[13:43:11] <nico> slide 4
[13:43:11] <jhutz> I thought this slide was worth it
[13:43:13] <eludom> packet want to go in one FE, out another.
[13:43:20] <jhutz> The slides are _not_ online
[13:43:35] <eludom> key is scale
[13:43:52] <nico> multiple 10Gbps ports
[13:44:01] <eludom> reliablity is extremely important....possibly even at the cost of security
[13:44:05] <nico> thus the FE/CE separation
[13:44:25] <eludom> ASICs on the CE for filtering DOSs
[13:44:34] <nico> slide 5
[13:44:35] <nico> slide 6
[13:44:37] --- sk has joined
[13:44:56] <eludom> ex. 1 BGP router 1000 peers
[13:44:59] <nico> 1000 peers -> 1000 admin entities
[13:45:19] <eludom> q: that is not typical
[13:45:27] <nico> kent: that's not typical except of internet exchanges, right
[13:45:33] <nico> how many have 1000?
[13:45:38] <nico> speaker: dunno
[13:45:45] <eludom> Ron Bonica:
[13:45:46] --- tlr has left: Replaced by new connection
[13:45:50] <cat> I'd be a bit surprised as well - I could see customer peering.
[13:45:55] <nico> bonica: (missed it :)
[13:46:09] <nico> kent: ISP with 1000 customers is the example then?
[13:46:17] <eludom> ron: I can think of a few examples
[13:46:33] <nico> mcr: the situation is often in the case more than 1/2 of those are IGPs
[13:46:52] <nico> I'm not sure I believe 1000
[13:46:57] <nico> but I can believe 3 digits
[13:47:08] <nico> kent: it would be nice to get clarification on this
[13:47:21] <nico> because I assume the focus is on transport security
[13:47:29] <nico> ^IGP^IBGP^
[13:47:31] <nico> ...
[13:47:43] <nico> weis: another use case is in the MPLS world
[13:47:59] <nico> slightly different trust model in the service provider model than in the peering model
[13:48:19] <nico> re-keying is important
[13:48:20] <nico> slide 8
[13:49:04] <eludom> no need in some cases...confident of physical security of links
[13:49:49] <jhutz> ekr: not important to rekey session keys.
[13:49:50] <nico> ekr: it's not important to re-key session keys
[13:50:02] <nico> modern algs allow practically infinite amounts of traffic
[13:50:03] <jhutz> : modern algorithms can support infinite amounts of traffic on one session key
[13:50:14] <nico> (he's talking about 128-bit block ciphers, for example)
[13:50:15] <jhutz> : even DES, 2^32 blocks before rollover
[13:50:34] <jhutz> : only rationale that's appropriate here is for staff changeover
[13:50:40] <nico> so only authentication key re-keying is important
[13:50:47] <jhutz> : I do thins all the time; it's just not right
[13:51:00] <nico> weis: context is existing protocols/algs that have been deployed
[13:51:10] <nico> ekr: only because you're not using IPsec
[13:51:18] <nico> missed this speaker
[13:51:20] <nico> sorry
[13:51:34] <eludom> ???: running a router with 100 peers...no requests for rekeying in a year
[13:51:47] <nico> mcr: session re-keys, I agree with ekr
[13:52:09] <mrex> well, rfc1964 the Kerberos gssapi mechanism enforce a maximum lifetime on the session key to be derived from the lifetime of the Kerberos ticket that is used to establish the session -- and it is not exactly easy for apps to deal with the rollover smoothly
[13:52:13] <nico> no good reason for it, unless you're using new ESP and you run out of seq numbers (2^32 packets!)
[13:52:21] <nico> we re=key every 8 hours anyways
[13:52:40] <nico> but even so, I could make that 80 hours...
[13:52:58] <jhutz> : those systems good about not disclosing session keys even to a privileged operator
[13:53:09] <mrex> Microsoft entirely ignores this lifetime limit (because their apps are entirely unable to manage the rekey above SSPI)
[13:53:22] <nico> we're talking about changing, what, RSA keys when staff rolls over
[13:53:31] <nico> I'm skeptical that they would honestly do that in practice
[13:53:41] <nico> weis: we'll get into the details
[13:53:42] <nico> ...
[13:53:49] <jhutz> phb: I'm having difficulty working out the threat model here
[13:53:54] <nico> phb: having difficulty figuring out what the threat model is
[13:54:01] <jhutz> : there are trading boards where you can buy router passwords
[13:54:07] <nico> there are trading boards where you can buy...
[13:54:19] <nico> the dominant attack is the password to the router being lost
[13:54:25] <nico> if you lose that then it's game over
[13:54:34] <nico> so, my skepticism w.r.t. IPsec
[13:54:39] <nico> is much more fundamental
[13:54:51] <nico> it's a completely inappropriate thread model
[13:55:01] <eludom> sam: out of scope
[13:55:09] <nico> sam: we're talking about transport security for BGP routers
[13:55:21] <nico> it's legit to discuss whether we want in the open mic session
[13:55:24] <nico> but klet's not now
[13:55:31] <nico> wies: <back to presentation>
[13:55:33] <nico> slide 9
[13:55:36] <nico> we'd like to use certs
[13:56:01] <eludom> prevailing wisdome: CERTS are not appropriate. Need PKI
[13:56:02] <mrex> certs are evil -- for anything that is high performance and high throughput
[13:56:05] <nico> (read slide)
[13:56:24] <nico> ron: the piece of info you need
[13:56:26] <nico> sorry, ekr
[13:56:45] <nico> fingerprints as large as passwords
[13:56:56] <nico> you store those, not certs
[13:57:16] <nico> (I hear "ron", he said "eric" and then I recognized the voice)
[13:57:36] <nico> so, these claims are basically wrong
[13:57:41] <nico> belovin: I second that
[13:57:48] <nico> the need for PKI is often vastly overstated
[13:57:51] <nico> I don't nee a PKI
[13:57:59] <nico> I just need to know this is the key I gave you
[13:58:03] <nico> there's lots of ways to do this
[13:58:17] <nico> w/o necessarily having a root and key signing ceremony
[13:58:32] <nico> another way that costs almost no storage
[13:58:36] <nico> I sign your cert
[13:58:39] --- richard.barnes has left: Logged out
[13:58:42] <nico> I only have to store my key
[13:58:48] <nico> there's lots of ways to skin this cat
[13:59:13] <nico> without necessarily needing lots of storage or a PKI ekr: the app support consists of an IKE implementation and a hash DB
[13:59:17] <nico> ...
[13:59:26] <nico> second pont, the use model here is very diff
[13:59:33] <mrex> certs create an expectation of PKI, possibility of revocation, OCSP, policies, weird attributes, all of which is expensive to parse (code-wise any cycle-wise) and a real performance issue if it is not entirely ignored
[13:59:37] <nico> in a pk scenario users only see public key values
[13:59:45] <nico> noone writes these down in post it notes
[14:00:08] <nico> when the users leave they're not taking them
[14:00:12] --- mike has joined
[14:00:21] * nico is going to the mic
[14:00:41] <nico> someone else scribe
[14:00:45] <eludom> paul hoffman: can't expect ISPs to subscribe to 1 PKI...but 10 or 20
[14:01:34] <eludom> answer: lots of these answers formulated around business modles
[14:01:41] --- richard.barnes has joined
[14:01:52] <eludom> michael: you could put those 10 or 20 in firmware or floash
[14:02:19] <eludom> michael: IX can do the work...authenticate people..
[14:02:35] <mrex> one of the problem of X.509 certs is the pre-determined self-suicide on a particular (short!) date
[14:02:46] <ekr> What do you mean "short"?
[14:03:02] <eludom> michael: I've been to lots of interop bakeoffs. I've never seen a large router vendor make that easy unless you have 4000 road warriors.
[14:03:04] <ekr> You can set them to have 50 year lifespans.
[14:03:08] <mrex> 1 year, this is usually a few month after productive usage has started
[14:03:20] <eludom> michael: I've seen the code...but it dosn't get released.
[14:03:26] <ekr> mrx: sure, but that's only a choice of the CA.
[14:03:32] <ekr> There's no reason you can't use a much longer lifespan.
[14:04:02] <eludom> michael: I'm ripping out routers and putting in Linux because it works
[14:04:29] <eludom> nico: you're not going to be rekeying RSA keys because you might have tokens
[14:04:51] <eludom> nico: you're only worrying about autnhentiating operators to routers, not routers to routers
[14:05:02] <eludom> phb: speaking in favor of strong PKI
[14:05:26] <eludom> phb: key cerimonies simplify systems. N vs N**2 connectoins
[14:05:41] <nico> (still on slide 9 :)
[14:05:46] <eludom> phb: PKI for WiMAX going to be hosted (@ ietf ?)
[14:06:08] <eludom> phb: if WiMAX are going to do it, why can't you (large router vendor(s)) ?
[14:06:33] <eludom> eric w: Not saying PKI is bad. Point is the business model dosnt work.
[14:06:38] <eludom> moving on to secret keys
[14:06:59] <eludom> ekr: this whole silde (10) is silly.
[14:07:22] --- ldondeti has left
[14:07:26] <eludom> if you're using PSK, you need some syn
[14:07:54] <nico> bernard: this is giving me a big headache
[14:07:58] <nico> sam: hold to the end
[14:08:04] <nico> bernard: well, that's all
[14:08:05] <mrex> PKI is not all that bad, but the business models of CAs make a lot of things painful to unbearable
[14:08:20] <eludom> BGP re-keying ops procedures
[14:08:29] <nico> martin: we're no necessarily talking about commercial global CAs
[14:08:33] <eludom> want to do this without taking down BGP sesions.
[14:08:34] <jhutz> Re: PHB, no not at ietf. When Phill says "we", I assume he means Verisign
[14:08:59] <nico> slide 12
[14:09:03] <nico> more on re-keying
[14:09:04] <ekr> Why do we have people plow through these presentations once the basic premise has been beaten up.
[14:09:15] <eludom> Secret key rollover: we don't have a way to do that.
[14:09:46] <eludom> DoS issues
[14:09:55] <jhutz> Well, ekr, maybe not everyone agrees with you.
[14:09:55] <mrex> If the router vendor would operate a CA and issue certs for all of his customers for free, that would give PKI a really big push
[14:10:15] <nico> (you can make it so someone who knows the psk has to be an active MITM when changing the psk, so it's not so bad)
[14:10:16] <eludom> Want to minimize services, possiby including IKE
[14:10:19] <cat> mrex - that seems like a spectacularly bad idea.
[14:10:33] <ekr> Well, obviously some people don't agree with me, but I didn't see anyone speaking up. You've got a disagreement you want to voice.
[14:10:34] <ekr> ?
[14:10:56] <nico> cat: yeah, but substitute ISP for router vendor
[14:10:59] <nico> then not so bad
[14:11:01] <jhutz> Also, while I don't think this is true in the present case, I find it really annoying when someone starts to give background for a proposal, and people get up and chew up half an hour explaining how the background is broken and has all these major problems which turn out to be the things the speaker is proposing a solution for
[14:11:13] <nico> slide 16
[14:11:16] <cat> nico - that doesn't sound like an improvement.
[14:11:16] <nico> summary
[14:11:23] <nico> cat: yes it does!
[14:11:29] <nico> you have an SLA with your ISP
[14:11:30] --- FDupont has joined
[14:11:34] <jhutz> I've got disagreements with some things you've said, yes. For example, I don't think 2^32 is all that many packets
[14:11:40] <nico> you have a direct business relationship with them
[14:11:49] <mrex> I really whish the presentors had submitted their presentations in advance
[14:11:56] <nico> the router vendor, OTOH, might not
[14:12:49] <eludom> Sam: we are interested in security that is deployed, not necessicarily technically correct security
[14:13:00] <jhutz> The other presentation was submitted, and is available at the URL I posted earlier.
[14:13:08] <richard.barnes> nico, mrex: another application for the address-space PKI that's been proposed for rpsec?
[14:13:17] <nico> yes
[14:13:23] <cat> nico - that makes it even more annoying to change ISPs then.
[14:13:38] <nico> cat: no it doesn't, you just get your certs re-signed
[14:13:42] <mrex> If the ISP provide the routing equipment, configuration and support to the customer, then Yes, the ISP rather then the router manufacturer should operate such a CA
[14:13:45] <cat> "just" ?!?
[14:13:50] <nico> ok
[14:14:06] <nico> how bad that is depends on where else you use them
[14:14:35] <cat> nico - that sounds like an operational nightmare at best, and people seem incapable of handling web certificates reliable currently.
[14:14:37] <nico> if you're trying to leverage your direct relationship with your ISP for authenticating to 3rd parties, then, yes
[14:14:58] <richard.barnes> if the sidr/rpsec stuff goes through, you'll be re-signing / reissuing things anyway
[14:15:00] <nico> but it can still be useful when dealing with your ISP
[14:15:18] <cat> richard.barnes - I remain unconvinced that the SIDR/RPSEC stuff is at all sensible.
[14:15:19] <nico> so you end up with lots of credentials, so waht, we already knew we weren't going to have a true global PKI
[14:15:28] <richard.barnes> cat: well, that's another issue
[14:15:41] <eludom> ??? operator: IPsec on a BGP router is way to complex, unpredictable
[14:15:57] <eludom> tcpmd5 works pretty well, but has own issues.
[14:17:08] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[14:17:11] <eludom> michael richardson: Where can I help solve this problem ?
[14:17:20] <ekr> The relevant point here is that from a technical perspective IPsec with key fingerprints can be made to appear almost identical to TCP-MD5.
[14:17:28] <cat> Post to NANOG, get your skin flayed.
[14:17:29] <eludom> can we talk to people directly ?
[14:17:43] <mrex> the large the PKI, the more attributes of a certificate (including subject,issuer,subjectAltNames) must be looked at in order to reliably authenticate an entity -- a global PKI would be a nightmare in that respect
[14:18:18] <ekr> So, it's certainy possible that IPsec UIs are too complicated, but it's not a property of IPsec, but just the implementations, which everyone stipulates we need to change
[14:18:27] <nico> well, no, the more work the CAs have to do to ensure that the certs they sign are for who they claim to represent
[14:18:39] <eludom> phb: I want to see a threat modle.
[14:18:53] <tlyu> but the users don't see the protocol, they only really see the UI...
[14:18:58] <eludom> phb: else we're going to deply crypto, not securtiy
[14:19:32] * nico doesn't trust commercial CAs of today to do that well
[14:19:42] <mrex> that is what you can see in many areas -- app writers stick to legacy authentication schemes and just want the security guys to provide an encrypted channel...
[14:19:55] <nico> mrex: yes!
[14:20:01] <eludom> phb: start at securiting rrouting layer.
[14:20:03] <nico> that is what we need to provide in general
[14:20:18] <eludom> sam: look at SIDR WG
[14:20:19] <nico> and we're trying
[14:20:32] <nico> (BTNS, channel binding, ...)
[14:20:46] --- ogud has joined
[14:21:19] <eludom> Charlie Kauffman: What are you looking at as an alternative ?
[14:21:26] <eludom> 2385
[14:21:43] --- geoff has joined
[14:22:11] <eludom> ck: doe manual keys have to be rolled over every few hours ?
[14:22:20] <eludom> no, itmes are much longer.
[14:22:21] <nico> mcr talked about session key rollover every 8 hours
[14:22:23] <nico> ...
[14:22:29] <nico> (he wasn't endorsing that)
[14:22:35] <mrex> X.509 certs, and PKIs based on it, are fairly primitive in some respects. The current approach of building groups is to use a seperate CA for it
[14:22:42] --- idli has joined
[14:22:56] <eludom> pk: manual keying has to be trouble prone
[14:23:35] <eludom> paul hoffman: to sam: IPsec implmentatoin issues are huge. with X.509 "even huger".
[14:23:50] <eludom> ph: impacts people setting up reliable systems.
[14:23:52] <cat> ... never mind "IPSEC interoperability"
[14:23:54] <ekr> And with X.509v3, they're hugest.
[14:24:31] <eludom> ph: App Interface is so bad, it's a non-starter
[14:24:58] <eludom> nico: manual keying means manual rekeying
[14:25:16] <eludom> nico: if you do it for staff rollover...who often do they depart ?
[14:25:42] <eludom> nico: more often than you'd like to. ... so don't use manual keying...use tokens, etc.
[14:26:39] <nico> eludom: will you scribe?
[14:26:43] <eludom> yes
[14:26:46] <nico> excellent
[14:26:50] <nico> my hands are tired
[14:26:56] * nico thanks eludom
[14:27:04] <eludom> Dan R.
[14:27:44] <eludom> talks about need for better security consierations sections.
[14:27:52] <eludom> new AD
[14:27:56] --- gordon.lennox has left
[14:28:35] <nico> ops area
[14:28:36] <eludom> IETF charters go up to point of submission
[14:28:45] --- Dave Nelson has left
[14:28:50] <eludom> timelines are 1-3 years
[14:29:08] <eludom> lack of tooks are part of problems
[14:29:22] --- iljitsch has joined
[14:29:22] <eludom> also, review/issues impact time
[14:29:47] <eludom> Slide: Is anything wrong ?
[14:30:42] <eludom> 1/3 of "discsses" in IESG are security related
[14:30:54] <eludom> not only numbers, but quality
[14:31:14] <eludom> often problems found in last review are very deep
[14:31:56] <eludom> second problem: lack of consistency in opinons of security advisory group.
[14:32:13] <eludom> hard to get consistent answers
[14:32:46] <eludom> you follow the advice you're given at the start, but get different opinion at the end
[14:32:52] <eludom> more work
[14:33:11] <eludom> perception: not dealing with computer science, but black magic
[14:33:27] <eludom> reactions: leaving or finess the process
[14:33:32] <eludom> neither good
[14:34:12] <eludom> picked two examples
[14:34:47] <eludom> slide: BCP 61/RFC 3365
[14:34:52] <iljitsch> Going back to the discussion a few minutes ago... manual keying requires manual rekeying, and doing that often enough is going to be a pain. True, but that's not the whole story. With any kind of keying there has to be a secret inside the router, which can be compromised either if someone gains physical access to the router (they're often located at shared sites so this is a very real risk) or when someone with administrative access to the router leaves the organization. The only reason to rekey automatically would be to avoid exposing the "real" key to cryptographic analysis or brute force attacks on a per-packet basis.
[14:35:01] <eludom> problems with this doc
[14:35:29] <eludom> (missed first one)
[14:35:39] <eludom> second: needs applicablity statement.
[14:35:41] <nico> eljitsch: which is why I mentioned tokens!
[14:36:24] <eludom> slide: what's wrong wiith BCP 72/RFC 3552
[14:37:30] <eludom> problems can not always be solved in the sec consideratoins sectoin....e.g. if there are problems with the protocol
[14:37:40] <eludom> problem: timelyness.
[14:37:57] <eludom> references are obsoleted or updated.
[14:38:11] <jhutz> Slides for both this talk and the previous one are now available online at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66#wg-saag
[14:38:44] --- ogud has left
[14:38:57] <eludom> another problem: only a miniorty of docs follow this format
[14:39:08] --- geoff has left
[14:39:41] <eludom> slide: ideas for improvement
[14:40:14] <eludom> from rest of community: we need to understand what you (sec) want.
[14:40:31] <eludom> update 3552...become a living document
[14:40:37] <stefans> How is a living version updater permanently?
[14:41:14] <tlyu> "permanently" may mean "perpetually"
[14:41:17] <eludom> try to catch things earlier (not jus sec)
[14:41:43] <eludom> IESG talking about "early review" process
[14:42:09] <eludom> WG can ask for advisor to be attached to the document earlier (e.g. for security review)
[14:42:43] <eludom> Do a better job documenting requirements
[14:42:49] --- danyork has left
[14:42:55] --- Jim Galvin has left
[14:43:19] <eludom> e.g. info rfc documents guidelines for reviewing MIBs
[14:45:08] <eludom> education needed
[14:45:39] --- sftcd has left: Replaced by new connection
[14:45:39] --- sftcd has joined
[14:45:40] <mrex> How to design security into protocols? Design of secure systems is unfortunately quite difficult and can't be easily described nor easily understood. It takes a real learning effort, gather experience, grow paranoia and understand why&how other systems have failed.
[14:45:57] <eludom> done....questions.
[14:46:14] <eludom> Russ: security directorate has been improving reviews
[14:46:28] --- dcrocker has left
[14:46:31] <eludom> Russ: having every doc reviewed during last call. Late but better.
[14:46:53] --- iljitsch has left
[14:46:55] <eludom> Russ: making sure that any issues are resolved before it reaches IESG. 40 reviewers.
[14:47:24] <eludom> ekr: early review is an important idea
[14:47:40] --- leiba has left
[14:48:06] <eludom> ekr: concerned with direction. Notion that if we produce enough reference material then people can write secure protocols.
[14:48:14] <eludom> ekr: people don't read what we have.
[14:48:59] <eludom> ekr: people who have been designing protocols for 10 years still make mistakes.
[14:49:22] <eludom> ekr: 2 hours in a classroom or reading 50 pages of docs is not going to make it easy to write secure protocols
[14:49:36] <eludom> ekr: you need an expert. You need to develop a habit of thinking.
[14:50:05] <eludom> sam: to ekr. I agree, but training and education has it's palce. Plea for people to use TLS.
[14:50:52] <eludom> /send nico I'm going to have to cut out in about 5 minutes
[14:51:27] <eludom> smb: What we have now is much better than what we had, which is nothing.
[14:51:42] <eludom> smb: ekr is right. Security is a way of thinking. Paranoia.
[14:51:45] <cat> We don't think - We -know-
[14:52:04] --- ogud has joined
[14:52:14] <eludom> smb: security is not a cookbook.
[14:52:49] <eludom> smb: dont' expect it to be perfect
[14:52:49] <ekr> Of course, even just ripping off TLS doesn't help as much as you'd think. I spent an hour yesterday in a SIP TLS meeting.
[14:52:57] <ekr> And that's a protocol I helped design!
[14:53:00] <eludom> phb: I think we can do better via education.
[14:53:22] <eludom> phb: there are ways to stucture a document that make it easier to see what's missing.
[14:53:30] <nico> we learn more about secure protocol design over time
[14:53:41] <nico> thus the call for a live doc seems reasonable to me
[14:53:59] <ekr> Sure. But in the case of SIP, that wasn't even the problem. We just didn't clearly understand the requirements.
[14:54:02] <nico> if we were starting TLS from scratch there are things we'd do differently today
[14:54:22] <ekr> Oh, I didn't even mean TLS--just the wiring up TLS into SIP.
[14:54:26] <nico> thus ripping off from TLS isn't necessarily a good answer (it might still be, but that's not the point)
[14:54:39] <nico> true
[14:54:40] <mrex> using existing (proven) protocols from the security area rather than creating yet another one is certainly a good recommendation, but it appears that many app designers don't like the complexity and requirements of real security
[14:54:45] <ekr> (Nico: Not that I'm necessarily disagreeing with you about TLS, mind)
[14:54:50] <nico> first determine what an appropriate threat model is
[14:54:58] <nico> but even there things change over time
[14:55:13] <ekr> Nico: That's actually what 3552 says :(
[14:55:26] --- miaofy has left
[14:55:32] <nico> in a world w/o wireless our threat models are different than with wireless
[14:56:05] <nico> but then new EAP work may make that problem go away
[14:57:42] <eludom> eludom is cutting out for next WG meeting. Nico or others, please scribe.
[14:58:31] <nico> ok
[14:58:37] <nico> russ: close the line
[14:58:38] <mrex> even defining a threat model is a non-trivial task
[14:58:54] <nico> jhutz: first of all, I agree with everything ekr said last time he was at the mic
[14:59:06] <nico> howevere, 3552 does have some bits that need updating
[14:59:09] --- weiler has left
[14:59:11] <nico> some out of date stuff
[14:59:18] <nico> more importantly
[14:59:27] <nico> security is not something we can throw a book at someone
[14:59:28] --- sftcd has left: Computer went to sleep
[14:59:37] <nico> we need to have reviews
[14:59:48] <nico> we need to give consistent advice
[14:59:55] --- gurtov has joined
[15:00:02] <nico> and advice that is consistent with what the reviewers will say at the end of the process
[15:00:25] <nico> receiving advice that X is fine but later finding that the reviewer says X !fine, that sucks
[15:00:35] <nico> ...
[15:00:45] <nico> ekr: steve already said what I wanted to say
[15:00:50] <nico> will tell story anyways
[15:01:00] <nico> yesterday, discussion on SIP TLS
[15:01:05] <nico> we screwed it
[15:01:12] <nico> still trying to unscrew it
[15:01:28] <nico> we screwed it because I didn't understand SIP well enough, and they didn't understand TLS well enough
[15:01:30] --- FDupont has left
[15:01:32] --- richard.barnes has left
[15:01:34] <nico> ...
[15:01:38] <nico> (missed the rest)
[15:01:43] <nico> (you know, the advices)
[15:01:46] <nico> advice
[15:02:00] <nico> who's at the mic?
[15:02:06] <nico> (I should know his name)
[15:02:16] <cat> Sorry - missed it.
[15:02:44] --- vidya has left
[15:02:46] <nico> speaker: we offer advice that isn't useful
[15:03:02] <nico> "we can just use IPsec" or "over TLS"
[15:03:09] <nico> ...
[15:03:14] <nico> we aren't helping
[15:03:17] <nico> I don't have a solution
[15:03:22] --- Suzanne has left
[15:03:34] <nico> they think from operational p.o.v.
[15:03:36] <nico> not security
[15:03:46] <nico> we need to see things more from an operational [pov too
[15:03:47] --- miaofy has joined
[15:03:52] <nico> else we're not being useful
[15:04:13] <nico> we talk too much, don't help so much
[15:04:23] <nico> and we don't have all the tools we need to give them
[15:04:29] --- bert has left
[15:05:27] <mrex> If App Designers ask me how to secure their protocol/app, then they only want to know what API they need to know and which parameters they will have to pass in and get out. But when I start asking them about the usage scenarios and ask how they intend to handle credentials management, they get really confused
[15:05:34] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Logged out
[15:05:36] <nico> sam: it's too easy to get arrogant
[15:05:48] <nico> I do agree with the statement that only security ppl can do security
[15:05:54] <nico> but see, we create new security ppl
[15:06:08] <nico> the way to learn to think in the security mindset is to do it [security]
[15:06:22] <nico> the SIP folks are starting to get to where they create their own security solutions
[15:06:31] <nico> and that's how I think we'll solve this problem
[15:06:33] --- idli has left
[15:06:43] --- cat has left: Disconnected
[15:06:44] --- lha has left
[15:06:53] --- gurtov has left
[15:07:03] <nico> SAAG session over
[15:07:06] --- hartmans has left
[15:07:11] <nico> mrex: yes, but here in the IETF sec area
[15:07:12] --- ben has left: Logged out
[15:07:17] --- fenton has left
[15:07:19] <mrex> calling the APIs is usually the easy part. credentials management, authencation, ACLs, trust and configuring all that is the real problem that requires large efforts
[15:07:24] <nico> we deal with lots of things you might not where you are
[15:07:31] --- tlyu has left: Disconnected
[15:07:36] --- ogud has left
[15:07:50] <nico> i.e.,offering the GSS-API isn't always useful here
[15:07:55] --- kurosaki has left
[15:07:56] <nico> :)
[15:08:41] --- eludom has left
[15:08:58] <nico> gotta go
[15:09:01] --- nico has left
[15:09:08] --- sk has left
[15:09:16] --- jhutz has left
[15:09:32] --- kivinen has left
[15:09:55] --- ryu.inada has left
[15:12:55] --- danyork has joined
[15:12:59] --- danyork has left
[15:13:46] --- miaofy has left
[15:14:09] --- ryu.inada has joined
[15:14:56] --- kurosaki has joined
[15:17:24] --- weshardaker has left: Disconnected.
[15:18:43] --- stefans has left: Replaced by new connection
[15:18:54] --- ryu.inada has left
[15:19:40] --- kurosaki has left
[15:19:58] --- dumdidum has left: Replaced by new connection
[15:21:35] --- marcos.sanz has left
[15:21:48] --- stefans has joined
[15:23:22] --- shep has left
[15:24:18] --- stefans has left
[15:24:33] --- ekr has left
[15:26:09] --- mjo has left
[15:26:22] --- stefans has joined
[15:37:44] --- Jeffrey Altman has left
[15:47:39] --- mike has left
[15:59:13] --- stefans has left
[16:19:34] --- mrex has left
[16:35:45] --- psavola has left
[16:37:30] --- ogud has joined
[16:56:01] --- idli has joined
[16:56:37] --- idli has left
[17:18:47] --- ogud has left
[17:48:52] --- mrichardson has left