[16:28:08] --- galvinjamesm has become available
[16:28:33] <galvinjamesm> Is this in Grande B, the only Grande without an audio feed?
[16:33:40] --- kenh has become available
[16:34:16] --- raeburn has become available
[16:34:51] --- wrstuden has become available
[16:42:42] --- suz-isc has become available
[16:42:52] --- raeburn has left: Disconnected
[16:49:40] --- ohm has become available
[16:56:55] --- kenh has left: Disconnected
[16:58:41] --- kenh has become available
[16:59:52] --- hartmans has become available
[17:00:10] <hartmans> Yes, of course
[17:02:23] <galvinjamesm> Thanks.
[17:03:04] --- suz-isc has left
[17:07:15] --- wrstuden has left: Disconnected
[17:10:06] --- jishac has become available
[17:12:26] --- fenton has become available
[17:14:41] --- pbh has become available
[17:15:01] --- ohm has left: Disconnected
[17:16:11] --- wrstuden has become available
[17:16:29] --- wyllys has become available
[17:16:43] --- raeburn has become available
[17:19:02] --- ohm has become available
[17:20:08] --- warlord has become available
[17:21:46] --- yushun has become available
[17:23:05] <galvinjamesm> Is the meeting starting or started?
[17:23:19] <fenton> still starting
[17:23:20] --- tlyu has become available
[17:23:34] <warlord> gathering momentum.
[17:23:42] <raeburn> waiting for russ...
[17:23:48] <raeburn> ...who is now here.
[17:25:51] <raeburn> starting now.
[17:26:43] <warlord> SB: NIST decertified DES
[17:26:46] <warlord> *applause*
[17:26:53] <warlord> PERM BoF
[17:26:56] --- jhutz has become available
[17:27:33] --- suz-isc has become available
[17:27:34] --- saag has become available
[17:27:42] --- saag is now known as nico
[17:27:48] <galvinjamesm> warlord: you the scribe?
[17:27:56] <nico> fun stuff first
[17:28:20] <warlord> no
[17:28:34] <warlord> but nobody else has been doing it..
[17:28:34] <galvinjamesm> Would someone please channel a request for a scribe?
[17:29:02] <warlord> jhutz appears to be channeling you
[17:29:08] --- jaltman has become available
[17:29:17] <jhutz> I am apparently a fool. Having channeled the request, I was volunteered by the AD's
[17:29:19] <galvinjamesm> Thanks!
[17:29:20] <warlord> Right now the speaker is describing the background of PERM
[17:29:37] <jhutz> The speaker is the chair of the perm BOF; I forget who.
[17:29:50] <fenton> It's Mark Baugher
[17:29:54] --- pbh has left
[17:29:56] --- jis has become available
[17:29:56] --- larry has become available
[17:30:00] --- jhutz is now known as jhutz-as-scribe
[17:30:06] <jhutz-as-scribe> ...
[17:30:15] <jhutz-as-scribe> john card from echostar spoke about why satellite providers want perm
[17:30:20] * jis has changed the subject to: saag meeting
[17:30:34] <jhutz-as-scribe> mark baugher (speaker) sdescribe perm between provider&consumer
[17:30:41] * jis has changed the subject to: saag: The Security Area Advisory Group
[17:30:53] --- sakai has become available
[17:30:54] <jhutz-as-scribe> the one problem... we didn't present a threat model
[17:31:06] <jhutz-as-scribe> several of us probably had a few different models; made the mistake of not presenting
[17:31:33] <jhutz-as-scribe> Brief description...
[17:31:46] <jhutz-as-scribe> PERM is a key establishment protocol that has a rights/policy payload
[17:31:56] <jhutz-as-scribe> establishes keys to users, devices, or groups of devices
[17:31:58] --- mike has become available
[17:32:11] <jhutz-as-scribe> ... independent of licensing
[17:32:13] <jhutz-as-scribe> rights payload (didn't see this slide in the bof)
[17:32:22] --- shep has become available
[17:32:23] <jhutz-as-scribe> group of actions that can be performed on a content work
[17:32:41] <jhutz-as-scribe> questions rwt relationship of this to XRML; this happens in key establishment and is much simpler
[17:33:04] <jhutz-as-scribe> PERM opterates over the intertet beweeen a content provider and consumer, typically over a home network
[17:33:20] <jhutz-as-scribe> pro's & cons
[17:33:23] <nico> conducible?
[17:33:41] <jhutz-as-scribe> con- no threat model
[17:33:51] <jhutz-as-scribe> con- opposes notion that data on your device is your data
[17:34:04] <jhutz-as-scribe> con- protocol will be used insecurely by licensed content protection devices
[17:34:15] <jhutz-as-scribe> con- IETF culture not conducive to this work
[17:34:35] <jhutz-as-scribe> pro- relieves providesrs of redundant non-interop systems
[17:34:40] <jhutz-as-scribe> pro- link/network independent
[17:34:58] <jhutz-as-scribe> ... better concensus; better review of how protocol would affect/be affect by other protocols in IP env
[17:35:19] <jhutz-as-scribe> we do have a charter; posted http://www.ietf.org/ietf/04aug/perm.txt
[17:35:32] <jhutz-as-scribe> first test is to develop a framework. take a look at tech used inside of perm that
[17:35:39] <jhutz-as-scribe> map to protocols, standards already in the IETF world
[17:35:47] <jhutz-as-scribe> consider replacing tech used in PERM with an IETF tech
[17:35:56] <jhutz-as-scribe> for example, msec should be considered
[17:36:01] <jhutz-as-scribe> ...then, rewrite spec and review
[17:36:13] <jhutz-as-scribe> plan: optimistically, complete work by end of 2005
[17:36:23] <jhutz-as-scribe> smb: note this is a proposed charter; this is still a BOF
[17:36:40] <jhutz-as-scribe> russ: today WG's are randomly ordered; you don't know when your number is up
[17:36:45] <jhutz-as-scribe> Next: SASL, Sam Hartman
[17:36:55] <jhutz-as-scribe> [when my number comes up, someone else must scribe]
[17:37:09] <jhutz-as-scribe> hartmans: SASL met for 1hr on Tues
[17:37:16] <jhutz-as-scribe> primary focus was sasl base spec, which is in WG last call, again
[17:37:26] <jhutz-as-scribe> we hope this will be the last. chairs concerned there is not enough review to progress
[17:37:33] <jhutz-as-scribe> really need to get more people to read the document
[17:37:39] <jhutz-as-scribe> last call expires at the end of this week
[17:37:45] <jhutz-as-scribe> starting to ping apps area people; get them to read doc
[17:37:59] <jhutz-as-scribe> one open issue: doc doesn't talk about rekeying; that will probably not pass muster
[17:38:15] <jhutz-as-scribe> then went on to digest-MD5. still have issue of explicit CBC IV's
[17:38:31] <jhutz-as-scribe> discussed GSSAPI. everyone agrees we need to maintain compat with kerberos mech, which is widely deployed
[17:38:43] <jhutz-as-scribe> proposing [missed what sam said, and I should know
[17:38:53] <jhutz-as-scribe> we expect to need 1-2 more revs of digest-md5
[17:38:58] <jhutz-as-scribe> expect to discuss gss issue on list
[17:39:14] <jhutz-as-scribe> saslprep seems to be done; anonymous, plain done at WG level
[17:39:22] <jhutz-as-scribe> russ: next, krbwg
[17:39:25] <jhutz-as-scribe> my turn
[17:39:31] <warlord> I'll scribe
[17:39:36] <warlord> until jhutz returns
[17:39:41] <warlord> KRBWG
[17:39:45] <warlord> jhutz speaking
[17:40:28] <warlord> krbwg met yesterday
[17:40:41] <warlord> found a last-minute "thing" to be improved.
[17:40:53] <warlord> have a base spec, crypto, gssapi ready to go
[17:40:58] <warlord> worked on pkinit
[17:41:27] --- sanjaya has become available
[17:41:40] <warlord> set-change password, info model, preauth framework, referrals..
[17:41:47] <warlord> krb extentions (next rev of core protocol)
[17:41:55] <warlord> questions?
[17:42:08] <warlord> (now, back to your regularly scheduled scribe)
[17:42:08] <jhutz-as-scribe> next, inch
[17:42:17] <jhutz-as-scribe> just met in last session. coming to conclusion on...
[17:42:22] <jhutz-as-scribe> two info models still progressing
[17:42:34] <jhutz-as-scribe> one thing we did discover. our original notion of no transport proto will not work
[17:42:46] <jhutz-as-scribe> need to identify one. likely soap [does he mean presentation?]
[17:42:56] <jhutz-as-scribe> [missed next item]
[17:43:00] <jhutz-as-scribe> next... pkix
[17:43:22] <jhutz-as-scribe> pkix met for 2hr on we
[17:43:22] --- jas has become available
[17:43:31] <jhutz-as-scribe> spent most of our time discussing ldap and ???
[17:43:41] <jhutz-as-scribe> have a whole bunch of LDAP specs[?]
[17:43:53] <jhutz-as-scribe> first draft on international text string comparison
[17:43:59] <jhutz-as-scribe> will clear the way for 3280bis
[17:44:15] <jhutz-as-scribe> decided to put together a design team for that; have given them an issues list
[17:44:24] <jhutz-as-scribe> got an issues list from pki4ipsec,
[17:44:36] <jhutz-as-scribe> if others have issues they can forward to us, that would be helpful
[17:44:43] <jhutz-as-scribe> smime met tues 1hr
[17:44:54] <jhutz-as-scribe> since last time, 5RFC's publshed, CMSbis, [???]
[17:45:13] <jhutz-as-scribe> [aaaaa can't followe what he's sayig]
[17:45:16] <jhutz-as-scribe> 4 other docs outstanding
[17:45:31] <jhutz-as-scribe> examples, ghost, km[?]
[17:45:40] <wyllys> GOST
[17:45:42] <jhutz-as-scribe> probably take until 2006, blocking on ANSI, ISO
[17:45:49] <jhutz-as-scribe> three presentations:
[17:45:55] <jhutz-as-scribe> format for long-term xxx signatures
[17:46:15] <jhutz-as-scribe> xx identtiy based encryption for S/MIME
[17:46:18] <jhutz-as-scribe> ipr and technical issues
[17:46:31] <jhutz-as-scribe> last was dfining a cert extension for S/MIME capabilities
[17:46:43] --- sommerfeld has become available
[17:46:45] <jhutz-as-scribe> next: ltans
[17:47:07] <jhutz-as-scribe> ltans met today 2hrs
[17:47:23] <jhutz-as-scribe> requirements doc stable
[17:47:36] <jhutz-as-scribe> doc concerning ???? underwent small revision
[17:47:42] <jhutz-as-scribe> main focus concerning protocol
[17:47:49] <jhutz-as-scribe> 2 prsentations - one describing, one about operation
[17:48:02] <jhutz-as-scribe> discussed role of notary services, what kind of work about this in future
[17:48:18] <jhutz-as-scribe> xxx
[17:48:23] <jhutz-as-scribe> next: mobike
[17:48:29] <jhutz-as-scribe> paull hoffman
[17:48:33] <jhutz-as-scribe> mobike met earlier this week
[17:48:38] <jhutz-as-scribe> group has been a bit slow since last meeting
[17:48:44] <jhutz-as-scribe> still trying to figure out all parameters of what we want to do
[17:49:08] <jhutz-as-scribe> 4, maybe 5 proposals for protocols. approaching differently no deployments yet, no pushng
[17:49:17] <jhutz-as-scribe> starting to get a graps on nat's and some other big issues
[17:49:24] <jhutz-as-scribe> within next month, will probably decide we know the problem space
[17:49:41] <jhutz-as-scribe> agreement once we had finished listing ideas we want to cover, the protocol will "just pop out"
[17:49:50] <jhutz-as-scribe> get through major work soon, then some residual work
[17:50:00] <jhutz-as-scribe> next;pki4ipsec
[17:50:04] <jhutz-as-scribe> met wed afternoon 2hrs
[17:50:18] <jhutz-as-scribe> working on profiling use of xxx certificates in IKE
[17:50:20] <jhutz-as-scribe> and...
[17:50:40] <jhutz-as-scribe> reviewed a doc that had rev'2 twice since seoul - ike cert profile
[17:50:52] <jhutz-as-scribe> profiling how to process certs within ike, how to issue certs, what goes in them
[17:51:00] <jhutz-as-scribe> major issues: better concensus on use of ipaddrs
[17:51:06] <jhutz-as-scribe> came to agreement on key usage, eku
[17:51:30] <jhutz-as-scribe> larger decision: discussion in ipsec about policy access db is going to happen in this instead of 2401[?]
[17:51:45] <jhutz-as-scribe> a few other nits, new version at end of week, hope to go to LC with -03 in september
[17:51:53] <jhutz-as-scribe> next doc, req's for cert management profile
[17:52:07] <jhutz-as-scribe> not going to consider xkms at this time - not strougn enough push - stick with crl via http
[17:52:29] <jhutz-as-scribe> came to conclusion vpn systems can authorize preauth cert issuance xxxx
[17:52:36] <jhutz-as-scribe> will rev document, targeting LC for dec
[17:52:50] <jhutz-as-scribe> ready to start thrid doc - actual profile that meeds req's doc. looking for editors
[17:52:55] <jhutz-as-scribe> updated milestones
[17:53:06] <jhutz-as-scribe> next: enroll
[17:53:12] <jhutz-as-scribe> paul hoffman
[17:53:27] <jhutz-as-scribe> enroll met this mtg; did not meet in seoul (no interest ina while)
[17:53:39] <jhutz-as-scribe> have overview draft; people on list start to agree this was a good place to start
[17:53:43] <jhutz-as-scribe> a few more contributors
[17:53:48] --- pbh has become available
[17:53:59] <jhutz-as-scribe> much of meeting was discussing -01 of that document; agreement much of it was good, could be expanded
[17:54:02] <jhutz-as-scribe> better momentum
[17:54:09] <jhutz-as-scribe> going forward, want to make sure xxx is good
[17:54:19] <jhutz-as-scribe> seems like protocol will pop out when req's are done
[17:54:25] <jhutz-as-scribe> we have a good shot at getting this out
[17:54:29] <jhutz-as-scribe> next:msec
[17:54:42] <jhutz-as-scribe> [speaker is not one of the chairs]
[17:54:50] <jhutz-as-scribe> last time we met in SD, were were a BOF.
[17:54:59] <jhutz-as-scribe> going through second recharting
[17:55:13] <jhutz-as-scribe> hope to finish in 2-3 more meetings
[17:55:24] <jhutz-as-scribe> met on mon morn; full agenda
[17:55:32] <jhutz-as-scribe> main new items are XXX v2
[17:55:40] <jhutz-as-scribe> ipsec sa's for multicast
[17:55:54] <jhutz-as-scribe> ipsec mapping for ???
[17:56:00] <jhutz-as-scribe> [I can't understand the speaker]
[17:56:07] <jhutz-as-scribe> next: kitten
[17:56:11] <jhutz-as-scribe> jeff altman
[17:56:25] <jhutz-as-scribe> "common authentication technologies next generatioin"
[17:56:30] <jhutz-as-scribe> met mon afternoon, successfully
[17:56:39] <jhutz-as-scribe> presentations on needs for clarifications to existing GSSAPI,
[17:56:53] <jhutz-as-scribe> extensions to existing GSSAPI to meet requirements discovered since cat conclulded
[17:57:03] <jhutz-as-scribe> at end of meeting, there was a straw poll.. >90 in attendance.
[17:57:19] <jhutz-as-scribe> when russ asked who would support & contribute to WG, _more than half raised their hands_
[17:57:23] <jhutz-as-scribe> we have a photograph...
[17:57:27] <jhutz-as-scribe> next: isms bof
[17:57:34] <jhutz-as-scribe> will meet tomorrow; nothign's happened
[17:57:36] <jhutz-as-scribe> next: mass
[17:57:57] <jhutz-as-scribe> "we held mass this morning for 2 and a half hours" <laughing>
[17:58:08] <jhutz-as-scribe> "message authentication signature standards"
[17:58:21] <jhutz-as-scribe> seek to solve similar problems to marid, but using crypto using ip addresses.
[17:58:26] --- sakai has left: Replaced by new connection
[17:58:30] <jhutz-as-scribe> marid charter calls for auth by ip address; crypto out of scope
[17:58:40] <jhutz-as-scribe> mass looking at ways of doing auth based on a signature computed on the message and
[17:58:47] <jhutz-as-scribe> authorized either in dns or elsewhere
[17:58:56] <jhutz-as-scribe> some common things w/marid
[17:59:00] <jhutz-as-scribe> - which address is the sender
[17:59:04] <jhutz-as-scribe> - marking success/failure
[17:59:05] <jhutz-as-scribe> - others
[17:59:17] <jhutz-as-scribe> about 7 different proposals, short presentations to illustrate what's going on
[17:59:29] <jhutz-as-scribe> 2 classe of proposals - signatures in headers vs S/MIME or something like it
[17:59:38] <jhutz-as-scribe> need to address different key management schemes
[17:59:51] <jhutz-as-scribe> different ways to canonicalise message to avoid breakage in transit
[17:59:58] <jhutz-as-scribe> how do you keep things working through mailing lists
[18:00:06] <jhutz-as-scribe> just this morning; I'm still absorbing
[18:00:12] <jhutz-as-scribe> there was a concensus to move forward as a bof
[18:00:20] <jhutz-as-scribe> need to analyze requirements, analyze threat model
[18:00:26] <jhutz-as-scribe> mailing list: ietf-mail-sig@imc.org
[18:00:36] <jhutz-as-scribe> last WG.
[18:00:43] <jhutz-as-scribe> russ: ipsec WG did not meet.
[18:00:51] <jhutz-as-scribe> they have basically 2 docs that need a few more cycles
[18:00:58] <galvinjamesm> shouldn't that be ietf-mailsig (sans the hyphen)!
[18:01:07] <jhutz-as-scribe> ikev2 has made it to the iesg; came back with a few comments; charlie will get a rev by tomorrow
[18:01:15] <jhutz-as-scribe> xxxxbis has one outstanding issue wrt icmp messages
[18:01:23] <jhutz-as-scribe> even though they're not here, ipsec close to wrapping up
[18:01:29] <sommerfeld> 2401bis
[18:01:42] <jhutz-as-scribe> next: Joe Touch, on "anonymous security"
[18:01:46] <jhutz-as-scribe> draft-touch-anonsec
[18:02:00] <jhutz-as-scribe> TCP RST attacks
[18:02:05] <jhutz-as-scribe> discussed in TCPM
[18:02:09] <jhutz-as-scribe> draft-touch-tcp-antispoof
[18:02:25] --- danwing has become available
[18:02:27] <jhutz-as-scribe> tries to provide a taxonomy of different ways of solving problem. 2 ways
[18:02:38] <jhutz-as-scribe> one provide auth/encryption, at net or transport layer
[18:02:53] <jhutz-as-scribe> other is through obfuscation - port randomization, xxx
[18:03:06] <jhutz-as-scribe> it struck me that there is a sense there (tcpm) that maybe it's necessary or OK to go around
[18:03:21] <jhutz-as-scribe> modifying every transport protocol because network stuff cumbersom to deploy
[18:03:27] <jhutz-as-scribe> need for anonymous security
[18:03:46] <jhutz-as-scribe> want to talk to someone, don't care who they are, but don't want conversation interrupted once it starts
[18:03:58] <nico> oh man, anonsec could be very useful in conjunction with channel bindings :)
[18:04:00] <jhutz-as-scribe> existing systems require authentication or preshared keys, which are cumbersome
[18:04:15] <hartmans> Nico, you're going to go talk to this guy, right?
[18:04:24] <nico> uh, yes
[18:04:29] <nico> duh :)
[18:04:34] --- kivinen has become available
[18:04:36] <jhutz-as-scribe> right now, people won't deploy what we have. it may be strong, but is too slow/cumbersome/etc
[18:04:41] <nico> expect me to get up and talk to him
[18:04:47] <nico> er, at the mic
[18:04:54] <warlord> Gee,a bunch of us wanted this oh... 5+ years ago and were yelled down.
[18:04:54] <jhutz-as-scribe> look at different places where we can provide optional mechanisms
[18:04:57] <nico> how timely
[18:05:04] <jhutz-as-scribe> hash exchange instead of full DH
[18:05:11] <jhutz-as-scribe> DH only instead of preshared secret
[18:05:29] <jhutz-as-scribe> simpler auth modes - header-only (first block), cookie-only (off-path protection)
[18:05:37] <hartmans> warlord: We're reevaluating a lot of our past sins
[18:05:40] <jhutz-as-scribe> at mic: nico
[18:05:51] <jhutz-as-scribe> one of the things we're doing in kitten now is channel bindings
[18:05:56] <warlord> hartmans: yes, but.....
[18:06:03] <jhutz-as-scribe> one of the things we'd like to have is anonymous ipsec
[18:06:14] <jhutz-as-scribe> have a channel that's secure; don't care about who the parties are, only that there is no mitm
[18:06:26] <jhutz-as-scribe> auth at app layer, then exchange bindings to the anonymous ipsec channel
[18:06:37] <jhutz-as-scribe> this has a number of performance benefits and so on
[18:06:52] <jhutz-as-scribe> combining network-layer anonymous mode with app layer auth
[18:07:12] <jhutz-as-scribe> nico: ok to have non-anonymous at network layer, but anonymous helps avoids multiple auth infra
[18:07:19] <jhutz-as-scribe> bill sommerfeld: I'd like to see a bof on this
[18:07:35] <jhutz-as-scribe> derek atkins: not a new idea. I remember talking about it last time we were here in SD
[18:07:39] <jhutz-as-scribe> I think it's a great idea.
[18:07:50] <jhutz-as-scribe> question is, is this a change to IKE, or another mechanism. how will it interface to IKE
[18:08:04] <jhutz-as-scribe> wesommer: let's not design it here
[18:08:10] <jhutz-as-scribe> warlord: talk to ipsec group
[18:08:20] <jhutz-as-scribe> nico: let's not try to invent new transport, just new key exchange
[18:08:43] <jhutz-as-scribe> hilarie orman: [missed what she said]
[18:08:53] <jhutz-as-scribe> david black: one of the reasons we need a bof is there is more than one threat model
[18:09:00] <jhutz-as-scribe> speaker and nico had different threat models
[18:09:04] <nico> (i.e., re-use ESP/AH)
[18:09:04] <jhutz-as-scribe> I want to see a bof on this
[18:09:14] <jhutz-as-scribe> smb: also in this space, opportunistic encryption
[18:09:28] <jhutz-as-scribe> speaker: yes. opportunistic encryption right now requires a pre-existing heirarchy
[18:09:39] <jhutz-as-scribe> charlie kaufmann: I'd like to strongly endorse this effort
[18:09:48] <jhutz-as-scribe> someone always says "we'll do it another way"
[18:10:04] <jhutz-as-scribe> I think this is a better definition of opportunistic encryption than what's done today w/DNS, whch is really
[18:10:11] <jhutz-as-scribe> just a lightweight keying infrastructure.
[18:10:40] <jhutz-as-scribe> next topic...
[18:10:43] <hartmans> Pondering interactions with HIP
[18:11:00] <jhutz-as-scribe> [annoying that I can't easily have 2 connections]
[18:11:15] <jhutz-as-scribe> ipv6 distributed security
[18:11:23] <jhutz-as-scribe> [who is this?]
[18:11:35] <nico> Jordi Palet
[18:11:35] <jhutz-as-scribe> draft-vives-v6ops-ipv6-security-ps-01
[18:11:45] <jhutz-as-scribe> draft-palet-v6ops-ipv6security-01
[18:11:53] <jhutz-as-scribe> (prob statement and reqs, respectively)
[18:12:17] <jhutz-as-scribe> please provide input. we are not really sure this will xxx
[18:12:30] <jhutz-as-scribe> we asked for input on saag list; please provide input
[18:12:45] <jhutz-as-scribe> next:
[18:13:03] <jhutz-as-scribe> ian bryant, exploit reporting
[18:13:22] <jhutz-as-scribe> there is a degree of synergy between this and inch
[18:13:27] <jhutz-as-scribe> looking to genereate an xml standard
[18:13:42] <jhutz-as-scribe> is there interest within IETF security community in progressing this through IETF
[18:13:48] <jhutz-as-scribe> ianb@nissc.gov.uk
[18:14:00] <jhutz-as-scribe> question: could you describe a bit more what you're thining?
[18:14:08] --- kivinen has left: Disconnected
[18:14:12] <jhutz-as-scribe> speaker: there are vast numbers of vulnerability advisories.
[18:14:21] <jhutz-as-scribe> most are issued in bulk text, hard to parse and deal with
[18:14:23] <nico> the more I think about it the more I like ANONsec, primarily because it will allow the iSCSI, RDDP, NFSv4 and other Transport Area folk to REQUIRE only a very lightweight KE protocol; but only if there is a new KE or a simplified IKEv2 profile for ANONsec
[18:14:36] <jhutz-as-scribe> at least 6 activities, all of trying to address this, none really conflict
[18:14:50] <jhutz-as-scribe> vendors may opt for different standards worse than unstructured text
[18:14:53] --- kivinen has become available
[18:15:05] <jhutz-as-scribe> ekr: there are a number of providers of vuln db's. they all have their own format
[18:15:11] <jhutz-as-scribe> are these guys interested?
[18:15:17] <jhutz-as-scribe> speaker: some major software vendors are
[18:15:33] <jhutz-as-scribe> ekr: what about the db maintainers
[18:15:43] <jhutz-as-scribe> speaker: not db vendors; mostly vendors and IR teams
[18:15:52] <jhutz-as-scribe> ekr: why are db vendors not relevant
[18:16:01] <jhutz-as-scribe> speaker: e.g. cve not interested
[18:16:17] <jhutz-as-scribe> ekr: seems like db vendors should be involved
[18:16:47] <jhutz-as-scribe> Q2: quick response - I can see there's not much initiative to do this
[18:16:55] <jhutz-as-scribe> xxx "we've done this thing and expect you all to support it
[18:17:02] <jhutz-as-scribe> db vendors could be involved
[18:17:17] <jhutz-as-scribe> [who was that? did I manage to transcribe right?]
[18:17:27] <jhutz-as-scribe> smb: any other security issues to raise?
[18:17:32] <jhutz-as-scribe> anything that requires extra attention?
[18:17:37] <jhutz-as-scribe> behave? marid? others?
[18:17:57] <jhutz-as-scribe> greg: went to behave; can't remember what area
[18:18:08] <jhutz-as-scribe> these (SIP) folks are trying to normalize NAT behaviour
[18:18:16] <jhutz-as-scribe> explicitly decoupling from access control
[18:18:35] <jhutz-as-scribe> trying to normalize behaviour so people who do NAT's can come to agreement, and
[18:18:43] <jhutz-as-scribe> we can write protocols to better get through them
[18:18:47] <jhutz-as-scribe> security implications...
[18:19:01] <mrichardson> PERM sounds ghastly, but I'd rather it was done here.
[18:19:03] <jhutz-as-scribe> a few wrt DOS, resource starvation. if not done right, people will be able to open up ports,
[18:19:06] <jhutz-as-scribe> fill state tables, etc.
[18:19:15] <jhutz-as-scribe> want to make people aware of it
[18:19:22] <jhutz-as-scribe> smb: anyone else?
[18:19:39] <nico> PERM needs to stop saying that tamper resistance is out of scope
[18:19:46] <jhutz-as-scribe> ?: rpsec - about security, requirements somewhat odd
[18:19:52] <nico> the crypto in PERM is useless without tamper resistance
[18:20:02] <jhutz-as-scribe> smb: we've heard that comment from others; it would be useful to have more sec folks involved
[18:20:30] <jhutz-as-scribe> [missed name]: we need more support; requirements may be "odd" because of operational requirements
[18:20:35] <jhutz-as-scribe> smb: anything else? open mike
[18:21:09] <jhutz-as-scribe> greg?: one comment, ask for a thought
[18:21:14] <jhutz-as-scribe> I know this is ugly; we need to address
[18:21:14] <fenton> [missed name] was Brian Weis
[18:21:30] <jhutz-as-scribe> it feels to me like I've been in many areas as an implementor and in a bunch of different WG's, where
[18:21:31] <hartmans> Shouldn't we ask the ISCSI question
[18:21:38] <jhutz-as-scribe> the right answer is probably to use certs, but "we can't do that".
[18:21:45] <tlyu> [? rpsec] was hillarie i think
[18:22:02] <jhutz-as-scribe> when pressed, certs unwieldy, unmangeable, could make it work if we tried hard but it doesn't
[18:22:05] <hartmans> Shall I get in line?
[18:22:11] <jhutz-as-scribe> a bit of a meltdown in pki vendor community in last couple of years
[18:22:16] <hartmans> (after this)
[18:22:18] <wrstuden> ňôSure
[18:22:21] <jhutz-as-scribe> we agree that base tech is right.
[18:22:32] <jhutz-as-scribe> for example, [xxx]
[18:22:36] <mrichardson> nico, anonsec involves adjusting software and protocols rather than just "failing to verify certificates", which OE can do.
[18:22:51] <nico> sam: maybe
[18:22:57] <jhutz-as-scribe> what do we need to do as a community to remove that response of "certs could solve the problem but we can't do that"
[18:23:04] <nico> ANONsec might simplify things for iSCSI/RDDP
[18:23:10] <kivinen> oh, we can just use "the internet pre-shared key" makemetastygoat....
[18:23:28] <nico> sam, I'll go to the mic
[18:23:30] <jhutz-as-scribe> unknown: I agree with greg; I don't believe that we spend a lot of time explainign bootstrapping
[18:23:33] <jhutz-as-scribe> to classical xxx
[18:23:43] <jhutz-as-scribe> [mumble mumble]
[18:23:48] <hartmans> The ISCSI question I was talking about is ike v1 vs ike v2 for rddp/iscsi
[18:24:00] <jhutz-as-scribe> [please folks, speak up and speak INTO the microphone, not just near it.
[18:24:02] <jhutz-as-scribe> ]
[18:24:10] <wrstuden> And please give your name
[18:24:36] <jhutz-as-scribe> smb: there's a lot of misconceptions out there
[18:24:48] <jhutz-as-scribe> the other day, I was talking with people.... said you need key exchange instead of static keys
[18:24:59] <jhutz-as-scribe> response "key exchange? that means we need a PKI; we can't do that".
[18:25:16] <jhutz-as-scribe> chris benotti: it seems that in pki, we've lost our roots
[18:25:31] <jhutz-as-scribe> we're afraid of edge complexity. too hard to solve problem on edge. client too complex
[18:25:32] <mrichardson> PK doesn't mean PKI.
[18:25:36] <jhutz-as-scribe> trying to push complexity back into the core
[18:25:39] <mrichardson> can we put that on a T-shirt?
[18:25:43] <jhutz-as-scribe> pki too hard; put keys into dns
[18:26:01] <jhutz-as-scribe> it seems like a lot of times, we're running away form the hard problem of engineering what we
[18:26:04] <hartmans> I'd buy the shirt
[18:26:04] <jhutz-as-scribe> really want at the edge
[18:26:13] <jhutz-as-scribe> [me too]
[18:26:24] <mrichardson> anonsec = OE with self-signed certificate or raw RSA keys in cert payload. But, you get SSH-like leap-of-faith possible.
[18:26:30] <sommerfeld> not only that, PKI doesn't mean X.509 and a verisign tax
[18:26:31] <jhutz-as-scribe> nico williams: want to bring up rddp
[18:26:41] <jhutz-as-scribe> I went to rddp. one draft could use review from sec area
[18:26:57] <jhutz-as-scribe> one issue they'll run into is that with advent of ikev2, they'll have to mandate ikev2, but iscsi already
[18:27:03] <jhutz-as-scribe> says ikev1, so they'll have to do both...
[18:27:12] <jhutz-as-scribe> probably iscsi needs an update to ikev2
[18:27:17] <jhutz-as-scribe> anonsec seems like a simplification
[18:27:20] <mrichardson> maybe someone can bring up that OE is in RFC-editor queue, as is IPSECKEY, and the next step is to have a BOF on "version 2"
[18:27:22] <jhutz-as-scribe> asking for some security review
[18:27:32] <mrichardson> I'm not in the room.
[18:27:36] <jhutz-as-scribe> david black, rddp chair:
[18:27:40] <jhutz-as-scribe> draft is the rddp security draft
[18:27:45] <jhutz-as-scribe> we'd love security reviews
[18:27:54] <jhutz-as-scribe> direction of wg now, most drafts headed for last call soon now
[18:28:19] <jhutz-as-scribe> direction wg intends to take is point to ips profile, "MUST ipsec, do it that way"
[18:28:29] <jhutz-as-scribe> derek atkins, channelling mrichardson:
[18:28:38] <nico> mrichardson: yes, ANONsec as a un-pre-shared self-signed certs is a way to go
[18:28:48] <nico> not necessarily the way to go
[18:29:07] <jhutz-as-scribe> greg: not ready to let go of my question. do we need to do something about this?
[18:29:12] <warlord> there's a lot to be said about the ssh model
[18:29:13] <jhutz-as-scribe> do we need a workshop?
[18:29:24] <nico> just a way
[18:29:27] <jhutz-as-scribe> smb: my perception is that a great deal of the problem is a human factors problem
[18:29:41] --- paul.knight has become available
[18:29:52] <jhutz-as-scribe> I'm the sort who thinks vi is a user-friendly interface. You don't want me designing the UI
[18:29:53] <nico> the problem with self-signed, un-pre-shared certs is that they're not needed for anon DH kex
[18:30:10] <jhutz-as-scribe> weiler: oe doc is not in RFC-editor queue; it's being held by the iesg
[18:30:13] --- mallman has become available
[18:30:18] <jhutz-as-scribe> hartmans: maybe there are some problems with pki
[18:30:19] <nico> otoh, since we have IKEv2, simply profiling it for ANONsec
[18:30:42] <nico> ANONsec re-keying will be a very interesting topic though
[18:30:47] <jhutz-as-scribe> there is a major sw vendor who's gotten an acceptable user experience, to the point where their
[18:30:57] <warlord> nico: they aren't needed but they reduce the mitm attack to a first-connect. Once you connect the first time you can verify the cert, cache it locally, and then you're never subject to a mitm attack again.
[18:30:57] <jhutz-as-scribe> uses will ask "how do I get security", and we say "you already have it"
[18:31:20] <jhutz-as-scribe> this redmond,WA-based software has not primarily deployed a pki solution
[18:31:36] --- wyllys has left: Disconnected
[18:31:45] <jhutz-as-scribe> in some cases move the problem not to the core of the net, but to the core of the auth system
[18:31:56] <jhutz-as-scribe> rather than trying to expect everyone to understand...
[18:32:11] <jhutz-as-scribe> not trying to tell everyone to go use kerberos (though that would be wonderful)
[18:32:14] <jhutz-as-scribe> <laughter>
[18:32:24] <jhutz-as-scribe> I disagree that pushing some problems to the core is wrong.
[18:32:32] <jhutz-as-scribe> xxx aggregate problems may make sec more deployable
[18:32:39] <jhutz-as-scribe> ekr: sometimes you need pki; sometimes not
[18:32:52] <jhutz-as-scribe> I remember back in stockholm, ca. 1997.
[18:32:54] --- wyllys has become available
[18:32:56] <jhutz-as-scribe> tatu shows up with ssh
[18:33:11] <jhutz-as-scribe> you had no way to know what the public key was of the server.
[18:33:20] <jhutz-as-scribe> server would say "my key is X", and you said "OK.
[18:33:33] <jhutz-as-scribe> everyone said "tatu, wtf is your problem?"
[18:33:43] <jhutz-as-scribe> strangely, we've survived well enough with this mode
[18:33:46] <yushun> a few claifications about ANONsec: (1) no cert is needed, we are talking about something closer to cookie; (2) yes, we need mods, but the target is not apps, but to mod IPsec to have a cookie mode
[18:33:55] <jhutz-as-scribe> is the threat model we're working with xxx
[18:34:13] <jhutz-as-scribe> smb: last time we were here in SD, there were active attacks against ssh sessions on our 802 network.
[18:34:16] <jhutz-as-scribe> ekr: sure, you can do it
[18:34:20] <jhutz-as-scribe> smb: it happened to us
[18:34:38] <jhutz-as-scribe> ekr: how many ssh connections do you have w/ certs for every server? ral, verisign certs?
[18:34:45] <mrichardson> yushun, just not interesting enough to modify software for. we can do it NOW, with very little effort, and get protection against mitm for all but first session.
[18:34:51] <jhutz-as-scribe> jeff schiller: Hi, jeff from mit, where we had a deployed pki
[18:34:59] <jhutz-as-scribe> we just reissued 35000+ certs in the last 2 weeks
[18:35:06] <jhutz-as-scribe> for pki to successful, it has to disappear
[18:35:18] <jhutz-as-scribe> it has to be just a button you push, a knob you turn
[18:35:32] <jhutz-as-scribe> in the history of pki, there's been the notion that it's magic we & our end users must worship,
[18:35:43] <jhutz-as-scribe> in the form of paying lots of money and dealing with lots of lawyers
[18:35:46] --- fp has become available
[18:36:14] <jhutz-as-scribe> we have no CPS. When we go to outside vendors and ask them to accept our certs, they don't ask
[18:36:23] <jhutz-as-scribe> what is our CPS, they ask how do we configure iis to do this?
[18:36:38] <jhutz-as-scribe> to deploy , you have to pass three tests. [damn; I missed what he said]
[18:36:50] <jhutz-as-scribe> hartmans: perhaps it's time we actuall commit to making our systems easy to use
[18:37:02] <warlord> inexpensive, easy, and incrementally deployable
[18:37:04] <jhutz-as-scribe> we have the tools, we need to focus on the usability problem, and on meeting jis's three tests
[18:37:18] <jhutz-as-scribe> why do we have a completely different auth infra for network access than for email?
[18:37:22] <jhutz-as-scribe> web somewhere in between?
[18:37:33] <jhutz-as-scribe> why don't we get our tech to work together, and make more usable in the process
[18:37:45] <jhutz-as-scribe> so we're not forced to deploy multiple auth infrastructures
[18:37:54] <jhutz-as-scribe> ?: because life sucks
[18:38:03] <warlord> hilary orman speaking
[18:38:17] <jhutz-as-scribe> maybe a document about looking into where xxx used would be useful
[18:38:36] <jhutz-as-scribe> I ran into a peculiar area. company went to a lot of effort to do certs, beta tested....
[18:39:02] <jhutz-as-scribe> I want to use the production version; they said "you don't have a cert; you had one for the beta version
[18:39:15] <jhutz-as-scribe> but can't have one for production" why not? liability
[18:39:20] <jis> The "Three Tests" (for the log):
[18:39:25] <jis> Cost Effective
[18:39:28] <jis> Easy to Use
[18:39:30] <jhutz-as-scribe> I think a doc would be useful to help people understand where they might get some benefi
[18:39:33] <jis> Incrementally Deployable
[18:39:34] <jhutz-as-scribe> smb: good idea
[18:39:40] <jhutz-as-scribe> not going to call for volunteers right now
[18:39:48] <jhutz-as-scribe> I will create a mailing list and post address to the saag list.
[18:39:49] <warlord> jis: ok, I was close.
[18:40:04] <jhutz-as-scribe> tim XXX, pkix co-chair:
[18:40:12] <jis> Tim Polk
[18:40:20] <jhutz-as-scribe> deploying any security takes some instituional will, pki takes a great deal more
[18:40:35] <jhutz-as-scribe> speaking from experience trying to deploy a ubiquitous pki for the fed govt
[18:40:40] <jhutz-as-scribe> we're getting there but it's taking time
[18:40:58] <yushun> Michael, I assume you mean OE. We looked at OE, but feel that "E" in OE is more than we need. Also, if I got it right, OE requires DNS or DNSSEC mods (the IPSECKEY stuff?) we'd also like to avoid that dependency. But we should definitely chat because they are many similar motivations between the two.
[18:40:59] <nico> time to mention SACRED? PKINIT?
[18:41:02] <nico> etc...?
[18:41:03] <jhutz-as-scribe> wouldn't build superhighways for one application; cheaper to drive the tractor across the grass
[18:41:38] <jhutz-as-scribe> marcus leech:
[18:41:50] <jhutz-as-scribe> nortel networks; until recently, a large org
[18:41:59] <jhutz-as-scribe> currently engaged in third attempt to get pki deployed
[18:42:13] <jhutz-as-scribe> unless completely transparent, if it even says anything about pki, they won't touch it
[18:42:31] <jhutz-as-scribe> paul hoffman: I'm going to try to tie together something from tim and from ekr
[18:42:37] <jhutz-as-scribe> it doesn't need to be hard. we have lots of sec mechanisms
[18:42:49] <jhutz-as-scribe> one always has to be hardest, most secure. pkix wins
[18:43:05] <jhutz-as-scribe> that's OK if it's obscure, not what we're telling everyone to use. but pkix is not obscure, we want it used
[18:43:11] <jhutz-as-scribe> can't say "oh well; that's the way it is"
[18:43:26] <jhutz-as-scribe> one option is to say "maybe we can help you find something not as hard to use".
[18:43:29] <jhutz-as-scribe> doesn't help us.
[18:43:45] <jhutz-as-scribe> PKIX stands for "PKI using X.509", that latter part has caused some problems
[18:44:14] <jhutz-as-scribe> underlying thing is, tie to X.509, a cert structure designed by database people for their current schema,
[18:44:22] <jhutz-as-scribe> has had signfiicant impact on deployment of pkix
[18:44:40] <jhutz-as-scribe> look at the lessons from simpler mechanisms: kerberos, ssh, passwords in the clear
[18:45:11] <jhutz-as-scribe> what can we learn from the other things we've had to tell people to deploy when they couldn't do PKIX
[18:45:20] --- Joe Touch has become available
[18:45:29] <jhutz-as-scribe> charlie kaufmann: wanted to sympathize with person who's saying "why aren't we just doing this"
[18:45:41] <jhutz-as-scribe> doesn't require a great deal of will; not that hard; doesn't have to be complicated.
[18:45:56] <jhutz-as-scribe> I worked on lotus notes. they had an installed base of ~50M certs.
[18:46:10] <jhutz-as-scribe> very successful because none of the users knew it was there. You just clicked on "encrypt all your mail",
[18:46:16] <jhutz-as-scribe> or admin did it for all users, and it just work.
[18:46:22] <jhutz-as-scribe> don't know why we're not doing it.
[18:46:35] <jhutz-as-scribe> I've met the guys in the black helicopters; they're not that clever. <laughter>
[18:46:46] <jhutz-as-scribe> the only thing that comes to mind, far side cartoon
[18:47:10] <jhutz-as-scribe> dinosaur in front of audience: "gentlemen, it looks grim. it's getting colder out there and we all have brains the size of walnuts"
[18:47:17] <jhutz-as-scribe> NAME????
[18:47:32] <jhutz-as-scribe> I don't think this is a protocols problem; it's a selling software problem.
[18:47:42] <jhutz-as-scribe> everyone trying to milk pki as a system, something you sell
[18:47:50] <jhutz-as-scribe> it's not a system. it's not somethign you buy; we want it to be invisible.
[18:47:59] <jhutz-as-scribe> you want your email, browser, network to be secure
[18:48:13] <jhutz-as-scribe> software has to be smart, security more embedded, more invisible
[18:48:17] <jhutz-as-scribe> can't sell it directly
[18:48:22] <jhutz-as-scribe> problem transcends the ietf
[18:48:41] <jhutz-as-scribe> what tim says may be true, but I don't think we should throw out baby w/ bathwater
[18:48:45] <jhutz-as-scribe> look at problem outside ietf
[18:49:04] <jhutz-as-scribe> nico: I think the ietf has been part of the solution;
[18:49:14] <jhutz-as-scribe> we have sacred, xxx, pkix, kerberos. just an implementation issue
[18:49:30] <jhutz-as-scribe> to some extent, it's an issue of past implementation choices
[18:49:42] <jhutz-as-scribe> until recently most browsers couldn't handle kerberos at all; don't understand why
[18:49:56] <jhutz-as-scribe> [WHO IS THIS?]
[18:50:09] <jhutz-as-scribe> don't believe that to be a true statement. complexity is an option
[18:50:20] <jhutz-as-scribe> historically, try to connect pki with national ID of some form
[18:50:28] <jhutz-as-scribe> what's hard is strong auth, registration of people
[18:50:33] <jhutz-as-scribe> leveraging of that does not have to be complex
[18:50:57] <jhutz-as-scribe> smb: created "easycert mailing list"
[18:51:10] <jhutz-as-scribe> https://www.machshav.com/mailman/listinfo.cgi/easycert
[18:51:13] <jhutz-as-scribe> uses self-signed cert
[18:51:20] <jhutz-as-scribe> speaker?
[18:51:40] <warlord> tim polk
[18:52:03] <tlyu> we still lack good free ASN.1 tools, IMHO
[18:52:10] <jhutz-as-scribe> marcus: I'd like to disagree with a commment made earlier
[18:52:12] <paul.knight> NAME??? above was Chris Bonatti
[18:52:20] <jhutz-as-scribe> that reason for grand failure of pki not due to us.
[18:52:26] <jhutz-as-scribe> pkix has a lot of knobs to tweak
[18:52:37] <jhutz-as-scribe> CA's that are unable to set the knobs in a way that are acceptable to clients
[18:52:54] <jhutz-as-scribe> so many knobs means lack of interop between CA's and clients who want to use those cas' certs
[18:53:03] <jhutz-as-scribe> greg: some data...
[18:53:07] --- sanjaya has left
[18:53:30] <jhutz-as-scribe> my customers don't see an roi in using PKI because buying a system that runs on an orcale backend hard to
[18:53:44] <jhutz-as-scribe> configure, many hours reading RFC's, etc is too much cost compared to savings
[18:53:48] <hartmans> Your customers should not have to read RFC. If your customers need to read RFCs you have a UI problem
[18:53:53] <jhutz-as-scribe> execs don't want us to develop because not enough customers
[18:54:01] <nico> heh
[18:54:02] <jhutz-as-scribe> ones that are using it, not doign so wisely.
[18:54:09] <jhutz-as-scribe> put 7MB of CRL info into a single CRL
[18:54:22] <jhutz-as-scribe> people who build routers don't want to use certs because they don't think they have enough nvram,
[18:54:27] --- mallman has left: Disconnected
[18:54:38] <jhutz-as-scribe> and they think it would take too long to issue certs on each of their cusomters routers strewn around environemnts
[18:54:41] <jhutz-as-scribe> no central management
[18:55:02] <jhutz-as-scribe> quite a bit of software on-box and in central management to make it work
[18:55:05] <nico> sam: customers often read RFCs because they're curious
[18:55:12] <jhutz-as-scribe> people don't want to roll it out because users can't handle it
[18:55:14] <nico> but they don't get a big picture that way
[18:55:33] <hartmans> Nico, need != curious
[18:55:38] <tlyu> so write informational overview RFCs?
[18:55:41] <jhutz-as-scribe> either (A) rolling it out requires a specific new software client on every machine; anytime that is the case it is cost prohibitive
[18:55:48] <jhutz-as-scribe> [gee, can anyone say scalable infrastrucutre?]
[18:55:52] <nico> we (the IETF, not just the implementors) should make that (big picture) available
[18:56:09] <jhutz-as-scribe> do we figure out how to tell the vendors how to hide it?
[18:56:09] <nico> sam: yes, I know
[18:56:15] <jhutz-as-scribe> is there stuff we need to do to help them hide it?
[18:56:31] <jhutz-as-scribe> smb: Jeff, how do your 35000 users get their certs?
[18:56:42] <jhutz-as-scribe> jis: they go to a web site
[18:56:47] <kivinen> I already requested gmane to subscribe to that easycert list under the name gmane.ietf.easycert. See gmane.org...
[18:56:53] <jhutz-as-scribe> jis:
[18:56:56] <jhutz-as-scribe> we have a 2-stage system
[18:57:07] <jhutz-as-scribe> users get certs by using kerberos credentials to go to a web site
[18:57:15] <jhutz-as-scribe> incoming students receive in postal mail a "coupon"
[18:57:20] <jhutz-as-scribe> list of phone numbers, rules, etc.
[18:57:26] <jhutz-as-scribe> in the middle is a 6-word phrase.
[18:57:32] <jhutz-as-scribe> which is the HMAC of their MIT ID and a secret.
[18:57:51] <jhutz-as-scribe> server that accepts them doesn't need a database
[18:58:07] <jhutz-as-scribe> for students who forget their coupon, they can go to student service center and get a new one
[18:58:18] <jhutz-as-scribe> (done via a web site with limited access)
[18:58:36] <jhutz-as-scribe> go to registration page, enter name, MIT ID number, and page, and register their account
[18:59:07] <jhutz-as-scribe> then they go to another web site, prompted for their username, kerberos password, and mit id, and
[18:59:12] <jhutz-as-scribe> generate a key and download a cert
[18:59:34] <jhutz-as-scribe> if you have two computers, we tell you "no problem, get two certs"
[18:59:48] <jhutz-as-scribe> they all have the same dn, but of course each has its own key
[18:59:57] <jhutz-as-scribe> for renewal, go to web site and push buttons
[19:00:07] <jhutz-as-scribe> some ui bits
[19:00:22] <jhutz-as-scribe> question: how big is your CRL?
[19:00:28] <jhutz-as-scribe> jis: we don't have a CRL
[19:00:39] <jhutz-as-scribe> how many people do you think have come to us saying "my cert needs to be revoked?"
[19:00:42] <jhutz-as-scribe> answer is "zero"
[19:00:49] <jhutz-as-scribe> not a problem we felt compelled to solve
[19:00:56] <jhutz-as-scribe> how many certs compromised? no clue
[19:01:05] <jhutz-as-scribe> if user doesn't know, how will they tell us?
[19:01:10] <jhutz-as-scribe> smb: "evil" bit will be set on packet
[19:01:12] <jhutz-as-scribe> <laughter>
[19:01:17] <jhutz-as-scribe> jis: some bits
[19:01:32] <jhutz-as-scribe> we have always have a fixed point where we know all certs will expire on that day
[19:01:39] <jhutz-as-scribe> (currently jul 5 2005 (?))
[19:01:48] <jhutz-as-scribe> used to be users got certs when they got to campus
[19:02:05] <jhutz-as-scribe> now they do it at home, before they arrive, since they need certs to participate in housing lottery
[19:02:12] <jhutz-as-scribe> a hack we did starting this year:
[19:02:29] <jhutz-as-scribe> if you are obaining a cert and you are class of 2008 and you are not on MIT network, your
[19:02:43] <jhutz-as-scribe> cert will not last past Sep 1; so, students not leaving cert on parents' computer
[19:02:50] <jhutz-as-scribe> which would allow access to grades, other data
[19:03:09] --- Joe Touch has left
[19:03:10] <jhutz-as-scribe> greg: there is a very small subset of humans in the world that could have strung together all the stuff that jis did
[19:03:15] <jhutz-as-scribe> to make the system useful.
[19:03:38] <jhutz-as-scribe> [missed name]:
[19:03:48] <jhutz-as-scribe> people are trying to do stuff w/security
[19:03:54] <jhutz-as-scribe> they do shy away from nasty things like ike, pki
[19:03:59] <jis> I will send a quick writeup to the mailing list (easycert)
[19:04:05] <jhutz-as-scribe> perception it's overblown, xxx
[19:04:19] <jhutz-as-scribe> trying to get end-to-end connectivity; asked to create another heirarchical infrastructure
[19:04:24] <paul.knight> Current speaker Mike Daley (sp?)
[19:04:25] <jhutz-as-scribe> without it, it just doesn't work
[19:04:39] <jhutz-as-scribe> we need something to trust which we know will be there
[19:04:46] <jhutz-as-scribe> like receiving a coupon
[19:04:52] <jhutz-as-scribe> routing, the dns, etc
[19:05:10] <jhutz-as-scribe> but if you're in routing, it's not going to be routing [because that's what your building --jhutz]
[19:05:12] <jhutz-as-scribe> smb:
[19:05:20] <jhutz-as-scribe> one of the things that's in various sec area documents
[19:05:31] <jhutz-as-scribe> there isn't, won't be, shouldn't be a global pki
[19:05:35] <jhutz-as-scribe> we don't want one
[19:05:38] <jis> People can also look at http://istwiki.mit.edu/istwiki/ItagCertificates It contains a writeup for our internal architecture group
[19:05:41] <jhutz-as-scribe> the nice thing about certs is you don't need one
[19:05:51] --- wyllys has left: Disconnected
[19:06:05] <jhutz-as-scribe> smb: please keep remarks brief
[19:06:23] <jhutz-as-scribe> wesommer: an observation - it takes a look at the entire system, not just wire protocols or single apps
[19:06:31] <jhutz-as-scribe> requires large-scale architectgure
[19:06:48] <jhutz-as-scribe> not clear how to address those within existing scope of the IETF
[19:07:03] <jhutz-as-scribe> aaron perez(?):
[19:07:18] <jhutz-as-scribe> to address issue about why we make it so hard. I think it is us.
[19:07:49] <jhutz-as-scribe> xxx is proposing a mech for ipsec to know if you're a "road warrior", connecting to a server, you have a way
[19:08:08] <jhutz-as-scribe> to know key is not compromised. Fine, but if it is compromised, the road warrior is screwed.
[19:08:16] <jhutz-as-scribe> name is [japanese, couldn't copy]:
[19:08:30] <jhutz-as-scribe> there has not been any BCP, little discussion about these issues
[19:08:33] <warlord> yasuo myakawa
[19:08:40] <jhutz-as-scribe> it seems it would be better XXX
[19:09:02] <jhutz-as-scribe> [missing this entirely]
[19:10:19] <jhutz-as-scribe> [sorry; got distracted]
[19:11:27] <jhutz-as-scribe> ??: do we need a group to talk about operations?
[19:11:31] <warlord> cheryl suggesteda pkiops
[19:11:36] <jhutz-as-scribe> smb: maybe; will bring up on saag list
[19:12:01] <jhutz-as-scribe> sandy roddy(?): I've spent the last 10 years trying to make PKI work in DOD.
[19:12:17] <mrichardson> thank you jhutz for the scribing. could someone buy him a beer.
[19:12:18] <jhutz-as-scribe> Able to get people who fly helicopters but don't know security to walk up to a kiosk and
[19:12:23] <jhutz-as-scribe> get the keys they need
[19:12:32] <jhutz-as-scribe> [kenh: talk to her and get youself a new smartcard]
[19:12:41] <jhutz-as-scribe> [sorry; I don't do beer]
[19:12:50] <mrichardson> pkiops. pronounced like "cyclops"
[19:12:56] <jhutz-as-scribe> giving people pki is not that hard; it can be done
[19:13:03] <jhutz-as-scribe> we have over 5M certs out there.
[19:13:09] <kenh> I can get a new smartcard, that isn't the issue. I just can't use it with anything.
[19:13:11] <jhutz-as-scribe> yes, our CRL is huge; we're deploying OCSP
[19:13:17] <jhutz-as-scribe> smb: closing lines
[19:13:29] <jhutz-as-scribe> doug engert: maybe the way to get PKI deployed in field is in stages
[19:13:33] <galvinjamesm> Thanks to the scribe! Great job!
[19:13:35] <tlyu> if your lifetimes are short, you have fewer worries about revocation...
[19:13:40] <jis> hear hear
[19:13:44] <jhutz-as-scribe> use something like KX509 to get a short term cert based on kerberos passwords
[19:13:51] --- mike has left
[19:14:02] <mrichardson> that's why CRLs are so nice for armies at war --- lives are very short :-)
[19:14:08] <jhutz-as-scribe> maybe you could then start using smartcards; to the user it looks about the same.
[19:14:13] <jhutz-as-scribe> but it gets apps, users used to using certs
[19:14:24] <kenh> It's great if you use windows; nothing else works.
[19:14:26] <jhutz-as-scribe> ????: I hope that produce BCP's XXX
[19:14:33] <jhutz-as-scribe> smb: about out of time; see you on the list
[19:14:34] --- paul.knight has left
[19:14:36] <jhutz-as-scribe> END
[19:14:38] --- jhutz-as-scribe has left
[19:14:43] --- jis has left: Disconnected
[19:14:45] --- kivinen has left
[19:14:47] --- galvinjamesm has left
[19:14:48] --- raeburn has left: Disconnected
[19:15:01] --- shep has left
[19:15:07] --- mrichardson has left
[19:15:21] --- kenh has left: Disconnected
[19:15:38] --- tlyu has left: Logged out
[19:15:56] --- wrstuden has left
[19:15:57] --- yushun has left
[19:16:37] --- hartmans has left
[19:17:40] --- pbh has left
[19:18:34] --- fenton has left
[19:19:29] --- warlord has left
[19:20:17] --- suz-isc has left
[19:21:20] --- jaltman has left
[19:21:55] --- nico has left: Disconnected
[19:22:59] --- jishac has left
[19:25:11] --- jas has left
[19:26:52] --- fp has left: Disconnected
[19:28:15] --- ohm has left: Replaced by new connection
[19:28:15] --- ohm has become available
[19:47:01] --- danwing has left: Disconnected
[20:03:43] --- ohm has left: Disconnected
[20:30:18] --- suz-isc has become available
[20:30:50] --- suz-isc has left
[21:05:17] --- ohm has become available
[21:14:22] --- raeburn has become available
[21:14:39] --- raeburn has left
[21:19:37] --- sommerfeld has left
[21:28:56] --- ohm has left: Disconnected
[21:29:46] --- ohm has become available
[21:47:14] --- nico-sun has become available
[21:48:57] --- nico-sun has left
[22:37:54] --- nico-sun has become available
[22:45:47] --- rlbob has become available
[22:46:10] --- rlbob has left
[22:46:46] --- nico-sun has left: Replaced by new connection