Changes between Version 4 and Version 5 of WikiStart


Ignore:
Timestamp:
30/10/13 21:36:19 (8 years ago)
Author:
ynir@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart

    v4 v5  
    22
    33== 08-Oct-2013 Virtual Interim Meeting ==
    4 Minutes will be posted soon! \\
     4Minutes are below! \\
    55For now, you can get the [[https://dl.dropboxusercontent.com/u/28687906/http-auth-virtual-interim-October-2013.mp3 | audio recording here]]
     6
     7
     8HTTP-AUTH Virtual Interim Meeting \\
     9Tuesday, October 8. 15:00 - 16:30 UTC
     10----
     11
     12Present at the interim meeting were:
     13* Yoav Nir
     14* Matt Lepinski
     15* Yutaka Oiwa
     16* Stephen Farrell
     17* Carsten Bormann
     18* Nico Williams
     19
     20The purpose of the interim meeting was to resolve open issues in the document:
     21'''draft-ietf-httpauth-mutual-00'''
     22
     23The following open issues were discussed at the meeting: \\
     24(See: [http://trac.tools.ietf.org/wg/httpauth/trac/query?status=new&component=mutual] )
     25* #2: Use of TLS Channel Binding for tls-key
     26* #3: A few issues with pwd-hash
     27* #4: Some issues with Authentication Realm
     28* #5: Is STALE needed?
     29* #6: Issues in Section 6
     30* #7: What is the value of non-mandatory auth?
     31* #8: Security Considerations Issues
     32* #9: Simplified protocol description "crypto paper"-style
     33
     34----
     35
     36The following action items resulted from the meeting:
     37
     38=== ISSUE #4 ===
     39The authors will produce text explaining the issue and, in particular, why they chose not to re-use web origin (RFC 6454). The authors will send this explanatory text to the mailing list.
     40
     41=== ISSUE #2 ===
     42The authors are hesitant to use the mechanism in RFC 5929 because they are concerned about the adoption status of RFC 5929 and don't want a dependency on RFC 5929 to hinder implementation of the mutal-auth mechanism. Several working group participants feel quite strongly that RFC 5929 is the future, and that HTTPAUTH is well-served to use the already-standardized channel binding mechanism.
     43
     44The authors will send a message to the list and propose a way forward on this issue.
     45
     46=== ISSUE #3 ===
     47The authors explained that this feature is present for backward compatibility with existing password databases. There were multiple opinions on the call regarding whether this backward compatibility is important. (That is, are entities that have large legacy password databases likely to migrate to Mutual-Auth if this backward compatibility is provided?)
     48
     49The chairs will start a discussion on the list to try to get input from a wider set of people regarding whether the PWD-hash feature is useful. The authors indicated they are willing to remove this feature if it turns out that the community does not think it is useful.
     50
     51=== ISSUE #5 ===
     52The next version of the Mutual-Auth draft will incorporate the idea of how long the server should keep session information
     53
     54===ISSUE #6===
     55The authors explained that this is not an issue that needs to be resolved. That is, the nonce in mutual-auth plays the role of the client nonce in the digest scheme and therefore it is correct that it be generated by the client.
     56
     57=== ISSUE #7 ===
     58The authors will move non-mandatory auth into the optional draft.
     59
     60=== ISSUE #8 ===
     61There seems to be a need for common text (in the HTTP-AUTH working group) for all password-using drafts to put into Security Considerations. The authors that have HTTP-AUTH drafts that use passwords will co-ordinate to produce appropriate considerations text.
     62
     63There was a request for the authors to add a reference to outside (non-IETF) documents that discuss the security analysis of the Mutual Auth protocol.
     64
     65The chairs will discuss with the authors off-line whether it is appropriate to loop in the CFRG for discussion of the security of the Mutual Auth protocol.
     66
     67=== ISSUE #9 ===
     68A request was made for a simplified description of the entire mechanism. (That is, on the level of "Alice sends this to Bob and then Bob replies with such and such".) The authors will see if they can come up with something appropriate.
     69
     70
     71
    672
    773----