IETF conflict review for draft-morand-http-digest-2g-aka
conflict-review-morand-http-digest-2g-aka-01

[Ballot comment]
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.

[Ballot discuss]
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?

[Ballot discuss]

- The httpbis wg are creating an IANA registry for HTTP auth
schemes, e.g. see [1]. 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 [1] 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 [1].)

  [1] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-08

[Ballot comment]


- The response message should maybe note that the httpbis
WG is also relevant.

- There were a couple of comments made when this was brought
to the attention of the httpauth wg. It'd be a fine thing if
the changes indicated were made. (The authors indicated that
they're ok with some of 'em at least.) The thread for that is
at [2]

  [2] http://www.ietf.org/mail-archive/web/http-auth/current/msg01544.html

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot discuss]
No matter how the Meaning of Life discussion plays out, I'm imagining that if HTTPAUTH is to produce anything, having Independent Stream documents popping out before the working group documents in the same space would be disruptive.

That's pointing me more towards

  3. The IESG has concluded that publication could potentially disrupt
      the IETF work done in the HTTPAUTH WG and recommends not
      publishing the document at this time.

[Ballot discuss]
No matter how the Meaning of Life discussion plays out, I'm having a difficult time imagining that if HTTPAUTH is to produce anything, having Independent Stream documents popping out before the working group documents in the same space would not be disruptive.

That's pointing me more towards

  3. The IESG has concluded that publication could potentially disrupt
      the IETF work done in the HTTPAUTH WG and recommends not
      publishing the document at this time.

[Ballot discuss]
No matter how the Meaning of Life discussion plays out, I'm having a difficult time imagining that if HTTPAUTH is to produce anything, having Independent Stream documents popping out before the working group documents in the same space would not be disruptive.

That's pointing me more towards

  3. The IESG has concluded that publication could potentially disrupt
      the IETF work done in the HTTPAUTH WG and recommends not publishing
      the document at this time.

[Ballot discuss]
No matter how the Meaning of Life discussion plays out, I'm having a difficult time imagining that if HTTPAUTH is to produce anything, having Independent Stream documents popping out before the working group documents in the same space would not be disruptive.

That's pointing me more towards

  3. The IESG has concluded that publication could potentially disrupt
      the IETF work done in the HTTPAUTH WG and recommends not publishing the
      document at this time.

[Ballot comment]
In view of Barry's questions, I wonder whether publication of this should be held until the working group has made its selection and published its preferred approaches.

Furthermore, at that time, I wonder whether the IESG would want to add an IESG note observing the existence of the WG documents and explicitly not recommending this solution.

I wait to hear more of the discussion before selecting my ballot.

[Ballot discuss]
I have a general issue with respect to this document that needs to be discussed:

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 draft draft-morand-http-digest-2g-aka-03
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

Its abstract says:
"This memo specifies a one-time password generation mechanism for
Hypertext Transfer Protocol (HTTP) Digest access authentication based
on Global System for Mobile Communications (GSM) authentication and
key generation functions A3 and A8, also known as GSM AKA or 2G AKA.
The HTTP Authentication Framework includes two authentication
schemes: Basic and Digest. Both schemes employ a shared secret based
mechanism for access authentication. The GSM AKA mechanism performs
user authentication and session key distribution in GSM and Universal
Mobile Telecommunications System (UMTS) networks. GSM AKA is a
challenge-response based mechanism that uses symmetric cryptography."

It was reviewed for me by Peter Gutman and Jim Schaad,
the authors worked with Jim to address the issues ot raised.


Thanks, Nevil (ISE)