IETF conflict review for draft-morand-http-digest-2g-aka
Summary: Needs a YES.
Ballot question: "Is this the correct conflict review response?"
I think Spencer has captured the correct resolution of Barry's questions, In addition to Spencer's proposal, I would suggest that we register the IESG's wish to be able to come back and add an IESG note at the time of publication. Best to put that request in now so that we don't fumble it when the document does get published.
This document has been submitted for publication as an Informational RFC through the RFC Editor. The IESG is doing a so called conflict resolution check on it, to make sure it does not conflict with ongoing IETF work, does not break IANA rules, and is otherwise not harmful for the Internet in some manner. But this is not a technical review. We generally let these types of documents through unless there is an issue. And having worked in this space before, I really like the work and welcome the new document. Thank you for working on it! However, I have a question mark and I think we should discuss an issue. The document is similar to previous specifications on EAP SIM/AKA (RFCs 4186-4187 and 5448) and HTTP Digest AKA (RFC 3310). It is also reminiscent of some work on the generic authentication framework at 3GPP (GBA). In those previous works, there was quite a bit of review of the crypto and protocol details before the specifications were published. What review has happened in this case? My e-mail search does not reveal much discussion, but my records do not go back very far. I do not remember seeing this earlier, but maybe my brain is in overload mode again. But I also asked the chairman of the 3GPP security group, SA3, Bengt Sahlin (Cced) if he had seen this, and he had not. So, what discussion & review has happened with the draft? Can you clarify? Note that while the IESG conflict review is not a technical review, I'm hesitant on what to do here, because at the same time we also want to be careful to not step on the toes of other organisations (3GPP in this case). I'd like publication of work affecting both organisations to be in sync. If such review has happened and enough people are aware of this, we should clearly move ahead. If not, perhaps this is something that SA3 (for instance) could review, just to make sure we are not creating some unexpected problems. Part of the reason that I am asking for this review is that when I looked (very quickly) at the document, it seemed to follow 3310 quite closely; the crypto is similar. However, in past work EAP SIM was somewhat different from EAP AKA in e.g., using n*Kc as opposed to Kc to use more key material. Similarly, GBA 2g version is different from 3g version. I have not done a deep enough review to understand whether similar differences exist/do not exist in this case or if they would be needed to begin with. But it was enough to cause me to ask the rest of you. Lionel, Bengt, can you say something about what kind of review has been going on wrt this document?
- The httpbis wg are creating an IANA registry for HTTP auth schemes, e.g. see . I think it'd be good for this document to be held until that registry is created and for it to add this scheme to that registry to save having to add it later. Note that  is apparently about to enter IETF LC, but the httpbis work hasn't been that quick (as its complicated) so that might impose some delay. I don't recall if the httpbis wg were asked about this recently. Note that I'm ok if this goes ahead and the schemes are registered later, but just want to check that the httpbis wg are ok with that, and I'd be happy to clear if someone says they will check or have checked. (Another approach might be to publish this and add this scheme to appendix A of .)  http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-08
I have a general issue with respect to documents like this that I wish we could resolve, but that I despair of resolving: This is very clearly directly connected with the httpauth work. They are chartered to look at a set of "better than plain/digest" proposals, and pick one or more to publish as Experimental. And so: in what sense does this NOT conflict with work in httpauth? The answer on the surface is that the WG doesn't want to consider this one. OK... but that brings up a more general question: Can *all* of the proposals that they don't want to consider simply be published through the Independent Stream? How about the ones that they do consider, and then decide not to proceed with? They could all be published as Experimental through the ISE. In that case, what's the difference between the ones published as Experimental by the WG, and the ones published as Experimental by the ISE? And, so, what's the point of that part of httpauth's work at all, then? The result of the discussion in the IESG was that the bottom line is that if httpauth doesn't want it, there is no conflict... and so I have moved this to a non-blocking comment. I remain vaguely concerned, but have no serious objection -- and certainly no specific objection to *this* document in particular.
I wait with interest for the answer to Barry's DISCUSS.
With Stephen's assurance that publication now will not disrupt work in the HTTPAUTH working group, I'm OK with the proposed conflict review response. I'm still interested in Barry's question, and I'm still interested in Adrian's suggestion that we consider an IESG Note to be included when the document is published. Thank you for addressing my Discuss.
... but support the idea of an IESG note
I'm not the expert on this matter. I'll go with the consensus of the knowledgeable ADs on this matter. Regards, Benoit