Phill Hallam-Baker (co-chair):
3 questions relative to WG items: - what do you plan to do? - what is chance of success? - will anyone care?
The starting point: things like OTP, secureIDs, etc.
- There is now much greater demand for this. - Initially, manufacturers did production, SS install; little issue in terms of provisioning.
Now: how do we address *shared secret provisioning for existing clients* such that only client and server know shared secret
Is this relevant to Kerberos? - does pk-init serve this role? pki provisioning protocols exist - does anyone really agree? no one spoke up...
(Jeff Hudson, Kerberos ): problem of setting up symmetric keys for cross-realm authentication have seen PK-based proposals over time for this problem can see how cross-realm could benefit with symmetric key
Proposed sketch of protocol (read: restaurant design) after Montreal, but won't introduce it unless interested, as may be too simplistic for general case.
(1) Mingling Pei, Verisign/Initiative for Open Authentication
Slides covered a wide variety of use cases at some detail
(2) Stu Vaeth Diversinet/Initiative for Open Authentication
Slides focused on sets of MUST, SHOULD, MAY and NON requirements
(1)
(Russ Housley Housley): concerned about multiple credential types combined with multiple condential containier formats (doesn't want see MxN combos)
(answer>: wants to be able to support existing vendor-specific formats
(Russ Housley ): doesn't want to have support of vendor-specific blobs all over the place
(Sam H. ): some folks don't want to see multiple formats, but his feeling is prefers easy to use as highest preference, even if tradeoff is multiple formats
(Ming ): will be considering PKSC (portable symmetric key containier), PKCS
(2)
(Rich Graves): - Don't understand security model... what is security considerations here? - how did I get a 20-bit token to get me large secrets (e.g. 128-bit)?
(Phill Hallam-Baker ): - use case here is only 20-bit token in both directions - can use pki/ssl for getting more bits - if only token, vulnerable to MITM on initial, but once past that point should be secure - e.g. smime certs protected with passkey that has fewer bits than the actual certs - assumption is actually either leap-of faith or ssl cert, etc.
(Phill Hallam-Baker ): - problem area is reducing fraud loss rates, but not to provide the level of security that we're all familiar with
(3)
(Charlie Kaufman): - ability of server to download same credential into multiple devices?
(Phill Hallam-Baker ): might be in use cases... ex. what if I lose my phone? but not convinced this is a real case... ex: key w/counter
(Charlie Kaufman ): no opinion, but it might influence somewhat the protocol deisgn...
(Charlie Kaufman ): requiring ability to change credential w/o id... basis?
(answer ): used in otp systems today userid --> token id --> credential if user has to change credential, don't have to change lots of backend systems
(4)
(name): - if have new secret each time I lose phone, the 75+ servers that I have relationships with I have to make changes for (validation server) - strong requirement: don't have to rely on a single validation server...
(answer) : that's already true...
(5)
(Jeff Hudson): - how you do or don't do auth is out of scope - whatever provisioning protocol we choose doen't require change id, but we don't need to force it on everything...
(1) Andrea : the crpyto token key initi protocol
(2) Ming (Verisign), et. al: dynamic symmetric key provisioning protocol
(Phill Hallam-Baker ): we've seen two prezos on protocols can we choose one or other or merge the two
Stu Vaueth: has come up with a matrix for aiding decision line items: requirements, then yes/no as to whether supported by proposal y general comments: they align fairly closely (especially in the mandatory requirements), major differences is in how certain thigns are done...
(Sam Hartman ): How I interpret requirements is different from how protocol developers interpreted it how auth is supported is kinda hackish and not extensible concerned about this in the non-secure channel case tired of ietf protocols coming out with half-baked auth (because "auth is hard")
(Phill Hallam-Baker ): assumption that we give someone a token that they can use for auth if smartcard, we can use point is if we had something better, we wouldn't be here
(Sam Hartman ): If i'm deploying otp, i'll use it everywhere except for bootstrap but I will need infra for boostrap (e.g. activtion codes) if I have another infra for doing auth, and provisioning mech doesn't support it, is that prov won't be adopted support existing auth infrastructure for provisioning lack of extensibility means that existing auth mech not supportable
(Bernard Abboba ): can't auth cert with cert?
(Phill Hallam-Baker ): do people agree that we have something to do here? technical likely since we're already doing it feedback on problems is still helpful
(Charlie Kaufman ): use cases
(a) device can make connections to net
(b) device can't make connections to net (request, etc., via 3rd entity) do we want just to define protocol for what's sent on wire?
(a) should have sufficient security mechanisms (albeit not standardized)
(bernard ): hard to validate trust anchor on device which has no display... lack of display may make it harder in general...
(Phill Hallam-Baker ): we need to talk with kerberos folks in general, but should charter specify writing a kerberos binding? is there a need (or yes, but in a later phase)?
(Sam Hartman ): you can not do it, or do it right... don't treat as phase2 item, since it may influence design... can't bolt on afterwards... no comments as to whether or not to do it...
(name? Intel ): similar work has been done in wifi alliances (simple config...) for bootstrapping keys for devices... should take a look at the work
(Bernard Abboba): good idea to look at, caveat is that frequent provisioning will be problematic, increasing level of disclosure
(Phill Hallam-Baker ):
1. who would contribute to keprov WG if it was chartered? those involved with proposals david black ... about 11-12 hands raised
2. should it produce binding spec that's responsible for SS tokens (Sam Hartman): if we don't, why charter?
(Phill Hallam-Baker): how about a kerberos binding?
(Sam Hartman): how many people with kerberos experience would be willing to work on it? q: in what role? authoring (2) review ("we have a quota")
(Jeff H, kerberos ): defer kerberos until later stage in process... start with basics first
(Phill Hallam-Baker ): agree, look at merging two proposals first, then look at kerberos
(Jeff Hudson, Kerberos): hopes that kerberos will help to strengthen the proposal
Volunteer authors identified: Larry tsu, Jeff Rayburn
(Sam Hartman ): should we do kerberos work?
(Phill Hallam-Baker ) called hum: (silence), those against? (silence>
(Sam Hartman ): maybe we'll defer this...
3. charter bashing here or on list?
(Russ Housley ): start it now...
(Russ Housley ): how many formats per credential? wan'ts this answered before approving charter
(David Black ): one of causes for angst was mutilple credential and format types as separate reqts suggest combining as single requirement...
(Phill Hallam-Baker ): that's helpful
(Phill Hallam-Baker ): should formats be xml, as opposed to asn1/pkcs/etc.? shoudl binary format be allowed?
(Russ Housley ): consider store&forward deliver rquirements
(Michael Richardson ): s&f is important... can see applicability of "number of bits needed is > than folks want to type", but xml is too much interested in the one between me and my registry for dnssec...
< microphones are dying >
(Sam Hartman ): whta we're worried about with credential formats is same problems as nea...
(Phill Hallam-Baker ): issue of backwards compatibility to things like legacy auth systems..
(Sam Hartman ): is this an interop issue?
(Russ Housley ): yes... but maybe in terms of this what is sent is blob&type, and we don't go beyond that here... but is worried if we do care about format of blob...
(Sam Hartman ): is inteorperability we're looking for is that the provisioing server and intermediary needs info on ..try again as two questions
(a) provisioning server and token need alg specific knowledge and als specific code? (Phill Hallam-Baker): yes, can consider alg part of shared secret we haven't specified how device and server need to talk to each other...
(Sam Hartman ): maybe Russ Housley wants to know that intermediaries don't have to convert the blob to get things to work (e.g. intermediaries don't need algor specific knowledge)
(Russ Housley ): less concenred about outside (how we get it there), but inner part
(Phill Hallam-Baker ): iana part for formats? yes...
(Sam Hartman ): just say one credential format per algorithm and we're done... seems to have agreement
(Sam Hartman ): why is how to get to server out of band?
(bernard ): also doesn't understand, can see where it needs to be negotiated... can't do it out of band because of need of ...?
(Michael Richardson ): sounds an awful lot like eap (laughter) authenticators don't know anything about algs most useful eap methods are ones for establishing shared secret... considers how to wrap in eap (general outburst of "ooh/ugh"), eap should be enough of transport...
(Bernard Abboba): yes, it is true that some existing eap methods could use output of this... also true for some of this might be useful for provisioining where no network access, but... eap only for network access...
Sam Hartman: yes! read eap applicability statement!
(Phill Hallam-Baker ): charter may be a bit too specific in what it contains, but wanted folks to understand
(Sam Hartman ): likes charter, wants to see "prov needs to support deployment in environments where not existing auth infra as well as environ where there is..."
(Sam Hartman ): wants some degree of extensibility
(David Black ): likes 3rd paragraph of use cases we care about either charter or applic statement: define functional characteristics of devices where this applies... would like strong functional description...
[iscsi... may want to use this... question is why? better than sneakernet for long-term secrets... but doesn't want to add this to list of desired devices, since this could bog down the important issues...]
(Michael Richardson ): 1st pp is kerberos issue of inter-domain 2nd pp: having hard time linking this pp to first one... we're not doing inter-domain keyhing, we're not bootstrapping pki, but... more intra domain (we're not bootstrapping intra-domain, only with entities where I already have an existing relationship)
(Phill Hallam-Baker ): zones of ... boundaries are not what they were company would produce token, sell it to enterprise enterprise would set up auth system and deploy tokens
now: tokens associated with auth system after fact, outsourcing auth systems or confederated systems...
if everything done by one company, problem doesn't exist but since we're doing this across those boundaries, we have problem...
(Sam Hartman ): wants to see this for provisioning tokens, not 4107... don't use this to get from iscsi to something else...
(David Black ): agreeing that iscsi is out of scope... but wants a concrete functional description of what is the class of auth tokens targeted by this, and what is intiial state where you start...?
(Russ Housley ): need applicability statement and good security considerations...
( more mic problems? >
(Jeff Hudson, Kerberos ): cross-realm kerberos provision token for other realms can be useful...
don't need so much specific sceanrios in charter...
not a solution for auto key management, but for provisioning LT shared secrets..
(Phill Hallam-Baker ): chater did say otp, but had forgotten to change to long-term shared secret...?
(Sam Hartman ): want to actually draw line (ss tokens in, don't care about kerberos, wants iscsi out... and something else out..?)
willing to defer applicability staement to wg, but wants statement of AS in charter...
(Jeff Hudson, Kerberos ): generally likes charter... once propsed fixes made, pretty close
(Jeff Hudson, Kerberos):what 2nd pp saying is because this has bene done for pk, it seems obvious that it can be done, but current pk solutions not generalized to non-pk... had a couple of suggestions for charter edits...
(someone > 3rd pp should be first...
(Michael Richardson ): now understatns what problem is... but how will my mother use this in real life? when/where will this be used?
(Susan , chair): usb tokens
(Phill Hallam-Baker ): eventually, but likely still too expensive for random commercial end user/consumer
(someone again>: ... long statement, but lots of interrupting noise (cell, pc noises) grr..
(Phill Hallam-Baker reply): some of this already done in europe...
....
(Phill Hallam-Baker ): any more comments on charter? (seems to be no>
(Phill Hallam-Baker ): deliverables: protocol, key containment, applicability statement, refinement of use cases/ problem statement, how to do this in kerberos environment
any others? silence...
not comfortable with timelines yet, since first item is evaluating merging proposals
(someone3> 3gpp already has something: generic bootstrap arch for bootstrapping symmetric keys do we have any thought of looking at such ideas? stu: not yet (someone3 > any chance? stuart: write up use case in keyprov
(Dondeti ): this is pertinant... if we're busy talking about phones, there *are* other standards parties that we shouldn't be ignoring here... e.g. "gba"...
(Stuart Vaeth): agrees... but can't assume things like gba to all
(Phill Hallam-Baker ): while technical capability, service provider may have disabled it... so we can't rely on this
(Dondeti ): if this is untethered from cell (e.g. gba disabled), that this is a good avenue for exploration
(someone3 :> we already have something standardized for phone, if you come up with something else, adoption may be hard
(Phill Hallam-Baker): anything else?
(no)
(Russ Housley): hum time... "Should the KEYPROV working group be chartered?" hums in assent, no objectors...