Minutes for krb-wg at IETF66
IETF 66 - Montreal, QC
Kerberos Working Group
Mon, Jul 10 - 09:00 - 11:30
Chair: Jeffrey Hutzelman
Scribe: Larry Zhu
1 the meeting starts with blue sheet signing
2. followed by agenda bashing
3:. Jeff has two presentations, chartering, technical items
4. we have no comments:, on the agenda
3. jhutz: etype negotiation, pkinit, OCSP for PKINIT, have been published as RFC,
related work: kitten published two RFCs PRF APIs and GSS-APIs, extensions for Kerberos mechanisms
4. ECC-PKINIT completed last call
5, TCP extensions ID, WGLC completed, only one objection, considered rough consensus reached
6 naming and anonymity support IDs published
7. jhutz do last call next month for set/change password, nico states that it need new boil-plate, republished that is needed before the last call
8. referrals, there are some discussion and some open issues, ken will discuss it
9. extensions document, Tom, current status, it is delayed for other reasons, working on it, provide a due date of the document in the future
10. WGLC hash agility,and gssapi – WLC in November
11. http-kerberos published as RFC
12, Web authentication Enhancement, BOF on Friday, use HTTP negotiate, Leif, Nico, and Sam working on, getting around phishing, a lot different areas, support for open IDs, accounts from one site to another, HTTP authentication, and other authentication area, presentation given by peter, of overview
13, kitten, WGLC in last call, for domain based names ID
14,leitf, information model, no discussion, Leif, is this the work need to do, discuss later
15, Lary Zhu, Kerberos TLS preauth ID does not use the extension mechanism, Jhutz, next version is using that, this is an individual submission
16, jhutz talked about past accomplishments
cryptoframework, aes mechanisms, Kerberos clarifications, GSS-API mechanism, PKINIT, enctype negotiation, OCSP support for PKINIT
17, open ended charter is not best to proceed, charter need to be updated.
Presentations
Presenter: Shoichi Sakane
issues with xrealm authentications
XKDC presentations, progress, problems, forward secrecy, low cpu, intermediate KDCs knowing the session key, what should we do solve the problems: PKI for client auth, KDC trusts using PKI, KDC resolving names. Some experimental data presented
Questions: 16 seconds for an authentication with crossream, Sam: how much of delay is due to network, how many of delay due to network latency, CPU is very slow.
2), Kerberos Support for OTP, presenter: Andrea Doherty from RSA
based on passwords, SAM drafts
differences: disconnected tokens,
support multiple OPT algorithms
+ counter
challenge-response
Time
Time + counter etc
Password with OTP to harden key
Issues: one time password is short, present brute force attack,
Question: Sam encrypted timestamp, why not challenge response, get rid of clock synchronization?
What is the reply key? Not factored into the initial draft
Presenter: We will investigate this further, and make sure the next draft addresses how the OTP proposal would strengthen the reply key. Thank you for raising the point.
Nico questioned how the hardening values work, and what is the AS_REPLY key. Presenter: in the draft, no detail was provided on the meeting
Nico: what happens when the KDC does not know the key/OTP, hence the need to pass on third party to validate the preauth
Presenter: The current proposal only supports when the KDC can generate the OTP. Validation of the preauth may require integration with a third party API.
Sam, user knows both password and otp? Third party proposal, Jhutz: technical details off-line
Larry Zhu: RFC3962 suggests the hardening value should not go to the string2key parameters, should combine the hardening values with the OTP passcode instead.
Larry Zhu: do you have perf data when the iteration count is high, the concern is that high iteration count may slow down the KDC. Andrea, there is trick to do PBDKF2 only once, will follow up with details.
A long discussion on the charter: 1 hour 30 minutes
active work items:
ECC PKINIT
TCP extensibility
naming
anonymous
set/change pw
referrals
extension
hash agility
no objection to active work items
inactive work items
preauth FW
HW preauth
SAM
PKCROSS
PKTAPP
IAKERB
no objection to active work items
proposed work items
preauth
Jaltman, zero configuration, sam assertion in authorization, machine identity, etc, Kerberos X509 translation service, constrain delegation, unauthenticated cleartext, kdc referrals, perfect forward secrecy
pick up recent big things,
TLS extension, Sam, good starting point, influence the reply key, channel binding, not committing his protocol, but doing the work,
Not so much, Kerberos over TLS
Poll on Preauth work, yes
Poll on Work on PKCROSS, yes, Sam, not willing to charter on this
Kerberos via TLS uses nopreauth
LDAP schema, really critical works, implementers need to work on this.
Leitf, shipping products using ladp schame, Ldap based model, hard to deploy the new model
Nico, no vendor waited for the standards, that suggests there are little value of this work.
Cross-realm authentication: poll, yes, do the work
Nico, Standard information model, schema model, Sam, better reviews if workgroup items. Too late to standard, large deployed based.
Leif, multiple schema is fact of life, help on the work if exposed web interface
Sam, propose get nico to work on board,
Nico, people not felt to wait for standard, the investigation did not have traffic for a long time. A lot more, would it make a work item to make it move fast,
Sam: making it a workitem does not make it go faster, take the discussion to move offline how to move this faster.
Wyllys acked that, simon, like to get this done, not care how, he is using stuffs already used in the heimdal implementations.
Jhutz, are you things sufficiently baked, that can be made workgroup items
Jaltman, Kerberos x509 translations,
Jhutz, invite people to come to talk with us, if they do, we can work on it, people are not present in the discussion,
Jaltman, work on carring SAML authrorization, pseudo mechanism to expose SAML work.
Sam, do not think it should be in the character, it is not baked enough. Proboelm and requirements statements.
Leitf, saml via GSS-API
Sam, Things are not baken enough, may of them should be baken now.
All except extensions are realistic.
Cross-realm authentication: yes, do the work,
Preath, OTP: do the work
Ldap information model, offline, depend on list discussion
Technical discussions: 30 minutes
Naming and anonymous:
Larry Zhu: open issues, the criticality of AD-IF-RELEVANT, because authz data may reveal identity.
Cliff suggested it is OK to remove authz data because there is no identity.
Love: AD-IF-RELEVANT can not be critical
Jhutz: remove unknown authz data if it is in IF-RELEVENT
larry zhu: conerns of removing restrictions, but acked it is reasonable removing unknown if it is in AD-IF-RELEVANT, given it can be ignored by servers that do not understand it.
Another issues: expose the realm name to GSS-API caller for anonymous principal. Jhutz proposed to discuss it on kitten given the time constrait
Cliff said he has minor comments he would send to larry.
Hash agility proposal,
Larry Zhu, paChecusm not an issue from security perspective, will propose Octetstring2key(). There was discussion whether we need to solve the unauthenticated clear-text issue in AS-REQ, the consensus seems to be waiting for extensions
Larry Zhu, if the KDF solves the unauthenticated cleartext issue, it would be fine, but otherwise no additional change is justified.
referrals ID: User2user alias used by user to login, do we want to reveal all the servers, for privacy reasons
Larry Zhu: very happy about w.r.t progress made
Sam/Jhutz, is the ID ready for last call
Ken, not ready, some issues in the current draft, need to address editorial issues from larry zhu
Jeff Altman and Larry have volunteered to look at security considerations for referrals.
Ken said some data integrity protected.
Cliff said he would send to ken something that will go to the security consideration section