Skip to main content

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

Discuss


Yes

(Sean Turner)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ted Lemon)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES.

Ballot question: "Is this the correct conflict review response?"

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Adrian Farrel Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2013-09-26 for -00) Unknown
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.
Jari Arkko Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2013-09-26 for -00) Unknown
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?
Stephen Farrell Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2013-09-26 for -00) Unknown
- 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
Sean Turner Former IESG member
Yes
Yes (for -00) Unknown

                            
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-09-26 for -00) Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection (for -00) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -00) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -00) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2013-09-25 for -00) Unknown
I wait with interest for the answer to Barry's DISCUSS.
Spencer Dawkins Former IESG member
(was Discuss) No Objection
No Objection (2013-09-26 for -00) Unknown
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.
Stewart Bryant Former IESG member
No Objection
No Objection (2013-09-26 for -00) Unknown
... but support the idea of an IESG note
Ted Lemon Former IESG member
No Objection
No Objection (for -00) Unknown

                            
Benoît Claise Former IESG member
No Record
No Record (2013-09-26 for -00) Unknown
I'm not the expert on this matter. I'll go with the consensus of the knowledgeable ADs on this matter.

Regards, Benoit