[drinks] Stephen Farrell's Discuss on draft-ietf-drinks-spp-protocol-over-soap-07: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-drinks-spp-protocol-over-soap-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I just want to check one thing...

Section 5: why is there a MUST for Digest auth?  What'd be
wrong with TLS client auth here?  I do wish the WG had
considered some alternative to passwords, which don't make so
much sense in this use-case.  (BTW: You could chose HOBA here
I guess, but that's still in the RFC editor queue and not
supported by libraries so perhaps doesn't suit. But it'd work.
I'm an author of the HOBA spec though, so I'm biased:-) Anyway
- can you tell me if the WG considered dropping passwords
entirely and mandating TLS client auth be implemented?  If the
WG seriously considered TLS client auth already, I'll just
clear.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- General: why would one want to ever run this protocol
without TLS? Did the WG consider saying that TLS MUST be used?
Again, if you tell me you thought about it, I'll just clear.

- 7.1.2: The framework uses "Identifier" but here you use
"Identity" - it'd be better to be consistent I think and
"Identifier" is a lot better.

- section 11 is weaker than the corresponding section in the
framework draft. Two things: 1) why not point back to the
framework here? 2) shouldn't you say which of the
vulns/mitigations called out in the framework are relevant or
mitigated here?