IETF – krb-wg notes

Co-chairs:
Jeffrey Hutzleman
Larry Zhu

jhutz:
Agenda bashing:
preliminaries
doc status
last call
tech disc
	pre auth framework
	OTP
	x-realm directions
review and milestones
open mic
intended status of STARTTLS document

No agenda bashing

Additional topic:
soichi: Would like to discuss KDC option in DHCPv6

Sam's Announcement:
sam: AD last three years, stepping down, Tim Polk to become new AD for krb-wg
tim: we switched groups around when Pasi was selected, has most interest in krb-wg

Document Status:
jhutz: set/change password: needs new revision, then will forward to Tim
zhu: GSS cb hash-agility: Shawn will address Larry's comments this week (in an updated draft) and will also include another extension to allow a MIC w/the mech OID
zhu: since the new extension will consist of a substantial change there we be WGLC on the this change
jhutz: x-realm problem statement draft has been last called, chairs still need to perform the write-up
jhutz: may still need have comments on the ID

Last Call Documents:
jhutz: 4 documents that have been in ~WGLC (all jhutz's)
jhutz: ECC for PKINIT, Naming, Anonymous, Data Model
jhutz: ECC for PKINIT: LC ended 3/7/08
jhutz: No IESG eval comments on any of these Ids yet
jhutz: Naming: secdir issues and IANA registry comments given
jhutz: Anonymous: IANA registry comments given as well
jhutz: Any issues or LC comments from the audience?  ECC?  No.
jhutz: Naming:
	Sec-dir review issues from Steve Hannah
	Issues raised: Security considerations section does not sufficiently discuss when
	applications should not accept tickets where the client principal name is a well known name who's 	meaning that they do not comprehend.  Suggesting that if they did that access would be granted 	unintentionally given the special semantics of the name.  Steve asks how this might happen and 	why is this requirement important?
	Why would a TGS issue a ticket at all; how can the TGS issue such a ticket even if the service 	principal name is not known at all?
jhutz: Any discussion on this issue (to audience)?  No.
zhu: Assumptions that the reviewer were not aware of.
jhutz: include text to reference Anonymous to help clarify issue
zhu: one sentence or two to describe issue
zhu: Naming: p 3, section 1, 2nd paragraph.  Kerberos does not have reserved names
jhutz: Steve needs an example
tim: casual reader needs this explained in the sec cons section
sam: Steve is not aware that the KDC is not making authorization decisions
jhutz: This is the answer to his second question.
jhutz: reference to RFC4120 should be sufficient
tim: Can't implement this spec (Naming), w/o implementing 4120; this is an acceptable answer
tim: limitation of x-review, is that we can't review dependent specs
jhutz: new example; new draft or rfc editor note?
tim: new draft
jhutz: Anonymous: comments: gen-arc review, all editorial comments
jhutz: these last calls ended Friday
tim: on telechat in two weeks
jhutz: depends on Larry's changes
tim: need a stable doc one week before the telechat
tim: give me a week from Thursday
jhutz: data model WGLC finished last month (February 2008)

Data Model:
leif: does the model cover it all?
	Comments: Accurate but not necessarily complete.
	Tom: may have some flags missing – easy to fix
	Comments: Should the model describe any operations?
leif: Leaning towards not describing operations
leif: Comments (from Henry): Policy under specified or not at all?
leif: Policy under specified on purpose.  Typed hole for opaque policy
leif: Soliciting comments on anything missing
leif: Needs to be revised, some nits.  Should move forward.
zhu: Not sufficient, but did not point what was missing.  Solicit them to what is missing.
jhutz: Should model describe operations?
nico: Operations would cover set/change pw protocol?
leif: Don't see the value of doing this.
jhutz: Should or should not include operations (to room)?:
Should: half-hearted hum
Should not: a few hums
Undecided: a few hums
No operations is stronger.
leif: In regards to policy: difficult to derive consensus on mailing list.  Opaque policies are difficult to understand, but doesn't hurt to keep it in the information model.  Only comment, is this really necessary?
jhutz: To the alias; what is meant to be a policy, which policies should we make less opaque e.g. password policy
jhutz: Mandating an implementation that maps policies the way that, for e.g., the way that MIT does may be limiting.
leif: Don't agree, can specify a typed hole in this document, a later document can define specific policy.
jhutz: Send this to the mailing list and include in the document.
tom: Useful to make a distinction between policies used by KDCs for issuing tickets vs policies that kadmin uses to make password changes/modifications to the database are permitted?
sam: Agreed that the distinction is important.  Uncomfortable with the cases that KDCs do not choose to issue tickets.  Also concerned about policies that affect authorization data in tickets, should be lumped into policy of issuing tickets.  Could run into problems with interoperability with the KDC.
jhutz: We have standardize policies built into the protocol related to KDCs refusing to issue tickets because a principal is expired or a TGT has expired.
sam: important distinction and we should separate the two
jhutz: model should describe two typed hole policies
sam: yes, two policies: principal modification and ticket issuance
leif: Update from comments from Tom, not for sure what to do about incompleteness comments.
jhutz: Comments should describe in what way the data model draft is incomplete
zhu: Ask one or two implementers if the data model is complete and useful
jhutz: Larry and Love, will you review the document?
Larry, Love, and Shawn have volunteered to review the document
leif: Simon had also modeled Shishi around this data model

Technical Discussion of Pre-auth Framework:
jhutz: Sam will talk about pre-auth framework and open issues
sam: pre-auth framework, published a new version:
	makes a number changes that we agreed to
	brought back PA value in auth set (rename of auth sequences have not been made yet)
	One change; when we have a challenge response mechanism that is in an authentication sequence, 	we need a way to have the initial challenge to be carried.
	Now we have a new field that can only be present in the first element of the authentication 	sequence that contains the PA value pre-auth mechanism in that sequence
	krb-ext rules require that you make sure that the other peer understands the ext before using the 	new key
	significance complexity on how this interacts with PA sequences
	A couple of ways of resolving this complexity:
	container information in the hint or have iteration recursion
	This is not going to happen:
	when changing the key, you are going to know about whether the other peer supports the key 	change before you get to this point
	should be easy to specify, no one is going to need to implement it
	for completeness we should mention the issue, but we don't need add complexity
	chose recursion because it was easier to specify
	people should review between 06 and 07 to see if they agree
	
	wg discussion needed:
	if an authentication mechanism ends, the client sends a response to the challenge,
	the server accepts that response, but wants the client to continue with the next mechanism in the 	authentication sequence, the server sends back a PA_FX_HEARTBEAT message
	My proposal is to remove that message and have the client send both mechanisms (the last RT of 	the first mechanism and the first RT of the last mechanism)
	question on whether a check sum is needed
	doc needs to be aligned w/naming draft, there is still an open issue tag in the text
	please look at the anchor tags to see if there needs to be any discussion
	questions?
gareth: How did you decide to resolve the issue about how the client identified which authentication sequence it chose?
sam: It has not been done.  The last meeting we discussed: include the member of the authentication set or include a numerical index.  There an issue tag for that, that has not been resolved.
sam: preference was to include a numerical index, but no one really cared a lot
gareth: numerical tag or ASN.1 returned?
sam: numerical tag
gareth: tag is fine by me
sam: WGLC before I go on my next chunk of leave, April 18th
jhutz: April
sam: going to miss that, June?
jhutz: June for proposed milestones
nico: additional reviews between now and then?
sam: one or two reviews then send to WGLC.

Tech discussion of OTP:
gareth: update published based on discussion from wg
gareth: no major changes made
gareth: type identifiers fixed
gareth: added informational references to the OATH OTP mechanism, SecurID, and normative reference to RFC2289 (S/KEY mech).  Made this MTI, let's discuss this later
gareth: Another change; there is an OTP value sent to the KDC to be hashed.  This is for cases in which the KDC can not obtain the OTP value directly (not the OTP server itself).
gareth: Value that is used is the string identifying the KDC.  Change was made to clarify on how this value is encoded (request made by Larry).  UTF-8 fqdn.  If an IDN then use Nameprep to encode it.  Feed back requested on use.
gareth: Usage examples for different times of OTP algorithms (2/4 pass authentication, resynchronization, and PIN change) added in appendix
gareth: Added new “combine” flag to control use of challenge response mechanisms to indicate whether the challenge is combined with the KDC token state (current time or counter mech)
gareth: three open issues:
gareth: this ID currently depends on the pre-auth frame work
tim: not a problem
gareth: should the ID contain a MTI profile?
jhutz: the framework doesn't have MTI mechanism, but each application that implements the mech has one
jhutz: Kerberos does have MTI for encryption types, but is unusual
jhutz: Kerberos itself must decide itself if MTI
sam: PKIX (S)CVP, cert valid. protocol.  Two modes:
Server to provide validation or to does this for the client 
sam: modes not mandatory
sam: could have two documents one for each mode
sam: here we could say that we need to implement one of the two modes
sam: here we are creating two-interoperability clouds in one document
jhutz: at least three-interop clouds with OTP
tim: SCVP: working w/server in domain you knew or offer the service that you expected
sam: if you have securid, not a whole lot you can do to participate in an OATH infrastructure
sam: Question: Does the IETF prefer one of these technologies?  What is keyprov doing?
jhutz: good to have MTI mechanism: to get us to point where we can take any KDC and use OTP and know that it will work with every client
nico: If it's hardware then there is not much benefit to MTI.
gareth: Should we specify which profile should be supported by the implementations.
jhutz: Client support does not depend on which hardware you have in your hand.
jhutz: Still an interoperability issue here.
nico: Which tokens could you expect people to have?
jhutz: Need token and software on your client to support this
nico: Clients should work with any OTP
gareth: Parameters provided by KDC
jhutz: Room for clarification to make this clear
jhutz: Need to know which tokens you are using when you deploy your server.  Your server will have to change to talk to the OTP mechanism
tim: goal is to avoid having to change your clients when the mechanism changes on the server
jhutz: I believe we can avoid a MTI
mrex: the interface to the OTP system is too underspecified to claim that the client supports all of them
gareth: the information sent down is the same mechanism as the POTP mechanism for EAP: key id, algorithm id, service id (which allows the client to locate the key to use)
gareth: two challenges: challenge to the server and challenge to the user (ids the token type)
gareth: OTP algorithm identifiers in the IANA section, keyprov has the same situation
gareth: keyprov presenting a list of OTP mechanisms to IANA
gareth: Should we link these two?  Would have a single repository.
gareth: Baker and Hoyer on keyprov repository RFC
jhutz: The other doc will create a registry, this OTP doc will reference other doc and this doc will have no IANA considerations.  This doc will have a normative reference
zhu: initial flag and encoding domain name: not happy w/update on Kerberos standard references 
zhu: server key and KDC reply key: why do we have two keys?
gareth: server key derived from OTP value used to encrypt the nonce sent by the client, reply key is used in standard manner
zhu: should use different key usage value instead of different key derivations
jhutz: WGLC, when?
gareth: If not too many changes, end of April should be feasible
tim: aggressive, but doable

Technical Discussion Client Friendley X-realm:
kamada: frame-work has some issues
kamada: client-friendly x-realm
	recursive ticketing mode
	dynamic cross mode
PKCROSS impementation and specification
kamada: motivation
	problem statement describes several issues:
	reducing client work load
kamada: tradition x-realm operation: many service tickets are requested
kamada: client-friendly draft:
	delegating iterative task of KDC/server by impersonating the client
	dynamic cross mode: obtain a service ticket directly with the target realm
kamada: Both modes can be combined
kamada: PKCROSS implementation and activities
http://www.taca.jp/krb-cross-realm
jhutz: problems w/cross-realm, need evaluate solutions to these
jhutz: recharter with solutions to this problem set
jhutz: editors may have cycles to work on this (like PKCROSS)
jhutz: won't recharter before Dublin
jhutz: meet in Dublin to discuss work in this space
tim: have a number docs that are mature, certainly don't want to see you recharter at this time
tim: documents may be done by that time (Dublin), good time to think about this

Next topic: STARTTLS:
jhutz: STARTTLS, we've been sitting on this document (for intended status)
jhutz: Simon has posted a new version of the doc
jhutz: Milestone WGLC January 2008, move to WGLC end of March 2008
jhutz: Information or experimental, unless MTI in Kerberos 5.3?  Could publish now (info or exp) and then could promote it (proposed standard) for MTI?
jhutz: Sam has stated not to publish this on the standards track.
sam: should wait to publish it, should wait for Kerberos 5.3
sam: creates confusion if we decide to publish this on standards track now if we don't end up going this direction to 5.3 later, because this will get don't sooner for anything we would do for 5.3
sam: Publish as informational (from 3932, causes less confusion)
jhutz: a wg document
tim: Depending on 5.3 timing, 5.3 would obsolete the specification?
sam: Shouldn't confuse if published as informational.
jhutz: 5.3 could make mandatory pre-auth (FAST) or STARTTLS
tim: We should say that the technology is done by submitting a WGLC
jhutz: Doc status is up to the IESG.  But as a WG, we need to decide what we want.
tim: If the consensus blocking this issue is the status then I will have to research this scenario further.
jhutz: Milestone moved from March to something later (depending on when Tim finishes research on this)

Open Mic:
soichi: In regards adding a KDC option with DHCPv6, address of the KDC for the client.
Presented to DHCP-wg, no objection.  What option and what parameters do we need to provide for this?  Sent to alias, send comments.
nico: What about adding a default realm option?  What's wrong with DNS?
jhutz: DNS SRV record lookup already present
jhutz: Interesting that DHCP-wg is looking at new options for server discovery.  Was under impression that this behavior has fallen out of favor.
soichi: DNS is not always used, some restrictions.  Isolated from the Internet.  Hierarchical structure not present.  DHCP boot strap devices, DNS could be disabled.
nico: Have networks where client hasn't authenticated yet (hotel networks).  Option is not necessary.
tom: What configuration exists that implements this?
soichi: Device has it's own name and shared key between the KDC.
tom: Client doesn't know its realm name?

End Session