RE: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



And thanks for the changes in -08 to address this review - in addition to
what's noted below, -08 also addresses [B] w/more compact text than I had
suggested.

Everything that remains is down to editorial comments or nits.  I'll go send
a review of -08 to that effect.

Thanks,
--David

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx]
> Sent: Friday, December 26, 2014 6:40 PM
> To: Black, David; paul.hoffman@xxxxxxxx; mike@xxxxxxxxxxxxx; General Area
> Review Team (gen-art@xxxxxxxx); ops-dir@xxxxxxxx
> Cc: ietf@xxxxxxxx; http-auth@xxxxxxxx
> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07
> 
> 
> Hi David,
> 
> Again thanks for the follow up...
> 
> On 24/12/14 18:40, Black, David wrote:
> > Hi Stephen,
> >
> > Thanks for the response and initial updates - anything that I don't comment
> > on further is fine, and everything in this response should now be reduced to
> > requests for minor additional text changes:
> >
> >>> [2] Challenge verification and reuse
> >>>
> >>> This sentence on p.6 strikes me as subtly dangerous:
> >>>
> >>>    The challenge however is sent over
> >>>    the network so as to make it simpler for a server to be stateless.
> >>>    (One form of stateless challenge might be a ciphertext that the
> >>>    server decrypts and checks, but that is an implementation detail.)
> >>>
> >>> The draft elsewhere asserts or assumes that challenge reuse can be
> >>> prevented by the server or be time-bounded by max-age, and relies on
> >>> those reuse limits for security properties,
> >
> > [... snip ...]
> >
> >> Hmm. I think that HOBA ought not REQUIRE full replay protection
> >> in all cases, that is, it SHOULD be possible to deploy a server
> >> that is vulnerable to some replay. The reason is that we're trying
> >> to displace passwords here and I believe (without much hard evidence
> >> I'll grant you) that we'd lose some deployment chances if we were
> >> to insist on every single challenge being fresh.
> >>
> >> So I'd argue for no-change here, but would welcome further discussion
> >> evidence or suggestions for text that's not going to be so onerous
> >> as to weaken our chances of getting this deployed.
> >
> > The word "stateless" is bothering me,
> 
> That's HTTP for ya:-)
> 
> > as doing a good job of replay
> > prevention usually requires saving state to remember what has already
> > been seen.  The following change would address this concern:
> >
> > OLD
> >    The challenge however is sent over
> >    the network so as to make it simpler for a server to be stateless.
> > NEW
> >    The challenge however is sent over
> >    the network so as to reduce the amount of state that needs to be
> >    maintained by servers.
> 
> I don't see a useful difference, but I can buy that your wording
> is maybe better so I've made that change.
> 
> >
> > The rest of the text on replay, including allowing some replay (e.g.,
> > within max-age) is fine w/me.
> >
> >>> [4] TLS requirement level
> >>>
> >>> TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement -
> >>> first paragraph in Section 8.1 (Privacy Considerations).
> >>
> >>> If TLS is not a "MUST" requirement, at least a discussion of man-in-the-
> >>> middle (MITM) attacks seems to be in order.  There's no need for an>
> extensive
> >>> discussion of all of the security properties of TLS, but MITM attacks are
> >>> definitely worth a mention, and that could be complemented by a pointer to
> >>> suitable HTTP/TLS security considerations text elsewhere.
> >>
> >> I think that's covered where we note the potential for replay, which
> >> is what a MitM would/could do in this case. That is noted in both
> >> section 3 and in 6.1 and in section 8. I think we have it covered to
> >> be honest.
> >
> > Ok, in looking further at the text on TLS, I suggest clarifying the last
> > sentence in this text in section 1:
> >
> >    HOBA session management is identical to username/password session
> >    management, with a server-side session management tool or script
> >    inserting a session cookie [RFC6265] into the output to the browser.
> >    HOBA still requires TLS to prevent session cookie hijacking.
> >
> > This is not a requirement on HOBA interactions - it's on the overall
> > HTTP session.  Suggestion:
> >
> > OLD
> >    HOBA still requires TLS to prevent session cookie hijacking.
> > NEW
> >    Use of TLS for the HTTP session is still necessary to prevent
> >    session cookie hijacking.
> 
> As above:-)
> 
> >
> >>> [5] Section 5.3 - unrecognized key
> >>>
> >>> Paragraphs 4 and 5 in this section don't seem to belong here, and appear
> to
> >>> be written in a somewhat loose fashion, particularly around user
> verification.
> >>> A server that does what is suggested here could have significant security
> >>> weaknesses.
> >>
> >> Which specific weaknesses do you mean?
> >
> > In this text:
> >
> >    The server >>can<< then use some out-of-band method (such as a
> >    confirmation email round trip, SMS, or an UA that is already
> >    enrolled) to verify that the "new" user is the same as the already-
> >    enrolled one.
> >
> > and this text
> >
> >    Completion of the joining process >>might<< require confirmation by
> >    email, SMS, Captcha, and so on.
> >
> > the use of "can" and "might" appears to make user verification optional,
> > which is a poor recommendation for obvious reasons.
> >
> > The simplest fix would be to change both of those words to "ought to"
> > or "should" (lower case).
> 
> Ok, at this point I think we're more into tweaking for the sake of it
> so I've not made that change.
> 
> >
> >>> [A] ABNF encoding of alg
> >>>
> >>> In section 2, I see:
> >>>
> >>>    alg = 1*2DIGIT
> >>>
> >>>    o  alg: specifies the signature algorithm being used encoded as an
> >>>       ASCII character as defined in Section 9.3.
> >>>
> >>> Section 9.3 specifies a single digit.  How does that become 1*2DIGIT ?
> >>
> >> Huh? The current algs only use one digit, but the abnf allows for
> >> more. Nothing odd there that I can see.
> >
> > What if someone uses "01" instead of "1" ?  Adding the following variant
> > of your response (which is better than my initial proposal) would close off
> > this corner case:
> >
> > 	Algorithms defined in this document use only one digit; the ABNF
> > 	allows for two digits for future expansion.
> 
> But that's already clear. No change made for now.
> 
> >
> >>> [B] Section 5.3 - CPK vs. kid
> >
> >>> IIUC, the HOBA client sends:
> >>>
> >>>    HOBA-RES = kid "." challenge "." nonce "." sig
> >>>
> >>> If so, I don't understand how the server extracts a CPK from that.
> >>
> >> Via the kid yes.
> >
> > [... snip ...]
> >
> >> I'm not seeing an actionable issue that needs a change.
> >
> > The client sends a kid, but the server is supposed to recognize the CPK.
> > The description of the server's actions needs to start from the kid, as
> > kid->CPK lookup may fail.  Here's a possible text change:
> >
> > OLD
> >    In the authentication phase, the server extracts the CPK from the
> >    signing phase and decides if it recognizes the CPK.  If the server
> >    recognizes the CPK, the server may finish the client authentication
> >    process.
> > NEW
> >    In the authentication phase, the server uses the kid to locate its
> >    copy of the client's CPK.  If the server finds the CPK and recognizes
> >    that CPK as appropriate for use, the server may finish the client
> >    authentication process.
> >
> > That results in a couple of knock-on changes to generalize "recognize"
> > to "locate or recognize" - here's the first one:
> >
> > OLD
> >    During the authentication phase, if the server does not recognize the
> >    CPK,
> > NEW
> >    During the authentication phase, if the server cannot locate or does
> >    not recognize the CPK,
> >
> > The other one is similar.
> >
> >>> [C] RSA signature algorithm
> >
> > [... nit snipped ...]
> >
> >>> The minor issue is
> >>> whether that is the signature algorithm that's wanted, on which I'll defer
> >>> to the crypto experts on that (e.g., I seem to recall a negative saag
> >>> comment on PKCS 1.5 mechanisms in the past couple of months).
> >>
> >> Yes, it's fine for security and is correct for interop/deployment
> >> reasons. PKCSv1.5 encryption is what's less desirable if not done
> >> well and attempting to mandate PSS here would be a bad plan.
> >
> > Ok, that's what I wanted to see checked.  No problem.
> >
> >>> [D] Javascript local storage.
> >
> > Again, one word is bothering me - here's a suggested change to the abstract:
> >
> >    HOBA is an
> >    alternative to HTTP authentication schemes that require passwords and
> >    therefore avoids all problems related to passwords, such as leakage
> >    of server-side password databases.
> >
> > Remove "all" - or change it to "many" or "common".
> 
> I'm gonna stick with all - an implementation of HOBA can be
> vulnerable to many things, and one likely but temporary
> style of implementation (non-WebCrypto in browsers) will be
> vulnerable (as we note) but the protocol itself does avoid
> all password problems.
> 
> I'll post -08 in a few minutes with those changes.
> 
> Cheers,
> S.
> 
> 
> >
> > Thanks,
> > --David
> >
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx]
> >> Sent: Wednesday, December 24, 2014 6:15 AM
> >> To: Black, David; paul.hoffman@xxxxxxxx; mike@xxxxxxxxxxxxx; General Area
> >> Review Team (gen-art@xxxxxxxx); ops-dir@xxxxxxxx
> >> Cc: ietf@xxxxxxxx; http-auth@xxxxxxxx
> >> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07
> >>
> >>
> >> Hi David,
> >>
> >> Sorry for the slow response, end of year rush and all that...
> >>
> >> And thanks for the review, responses inline and a proto-08
> >> version (handling the various IETF LC comments) is at [1]
> >> with a diff vs. 07 at [2]. I'll plan to publish that as an
> >> official -08 in a few days if there are no comments.
> >>
> >> Cheers,
> >> S.
> >>
> >> [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt
> >> [2]
> >> https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-
> >> 07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt
> >>
> >> On 15/12/14 23:25, Black, David wrote:
> >>> This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both
> follows
> >> ...
> >>>
> >>> I am the assigned Gen-ART reviewer for this draft. For background on
> >>> Gen-ART, please see the FAQ at:
> >>>
> >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >>>
> >>> Please resolve these comments along with any other Last Call comments
> >>> you may receive.
> >>>
> >>> I have reviewed this document as part of the Operational directorate's
> ongoing
> >>> effort to review all IETF documents being processed by the IESG.  These
> comments
> >>> were written primarily for the benefit of the operational area directors.
> >>> Document editors and WG chairs should treat these comments just like any
> other
> >>> last call comments.
> >>>
> >>> Document: draft-ietf-httpauth-hoba-07
> >>> Reviewer: David Black
> >>> Review Date: Dec XX, 2014
> >>> IETF LC End Date: Dec 24, 2014
> >>>
> >>> Summary: This draft is on the right track, but has open issues
> >>>  		described in the review.
> >>>
> >>> This draft specifies a signature-based authentication mechanism for HTTP
> >>> that is based on asymmetric (public-private) key pairs without using
> >>> certificates.  A different key pair is used by each user for each for
> >>> each host ("web-origin", see [RFC6454]), and each signature is based
> >>> on a server-generated challenge.
> >>>
> >>> The draft is generally well-written and clear on the authentication
> >>> mechanics, but has weaknesses in specifying the environment that
> >>> surrounds use of this mechanism.  Some of these issues are basic things
> >>> that anyone working on web technology or applied crypto "just knows",
> >>> but even the obvious needs to be stated when it's integral to security.
> >>>
> >>> -- Major issues: --
> >>>
> >>> [1] Challenge size and predictability
> >>>
> >>> In the ABNF:
> >>>
> >>>    challenge = 1*base64urlchars
> >>>
> >>> I did not see any other discussion of minimum length of challenge
> >>> or amount of entropy in the challenge.  For the latter, do the challenges
> >>> need to be unpredictable?  I would think so.
> >>>
> >>> I think a requirement on minimum challenge size and a recommendation on
> >>> minimum amount of entropy would be good ideas.
> >>
> >> Fair point. And you're right that this is assumed and ought be
> >> explicit, so good catch.
> >>
> >> OLD:
> >>
> >>    o  challenge: MUST be a base64url encoded challenge value that the
> >>       server chose to send to the client
> >>
> >> NEW:
> >>
> >>    o  challenge: MUST be a base64url encoded challenge value that the
> >>       server chose to send to the client. The challenge MUST be chosen
> >>       so that it is infeasible to guess, and SHOULD be indistinguishable
> >>       from (the base64url encoding of) an at least 128-bit long random
> >>       string.
> >>
> >>>
> >>> [2] Challenge verification and reuse
> >>>
> >>> This sentence on p.6 strikes me as subtly dangerous:
> >>>
> >>>    The challenge however is sent over
> >>>    the network so as to make it simpler for a server to be stateless.
> >>>    (One form of stateless challenge might be a ciphertext that the
> >>>    server decrypts and checks, but that is an implementation detail.)
> >>>
> >>> The draft elsewhere asserts or assumes that challenge reuse can be
> >>> prevented by the server or be time-bounded by max-age, and relies on
> >>> those reuse limits for security properties, e.g., as in this sentence
> >>> near the end of Section 6.1:
> >>>
> >>>    Note that replay of registration (and other HOBA) messages is quite
> >>>    possible.  That however can be counteracted if challenge freshness is
> >>>    ensured.
> >>>
> >>> The sentence quoted from p.6 appears to allow (or even encourage)
> >>> stateless servers to implement rather weak checks on not only challenge
> >>> reuse, but also challenge validity (e.g., what if the challenge validity
> >>> test were "challenge mod 1024 == 7" ?).
> >>>
> >>> Allowing such weak checks could enable an attacker to choose or influence
> >>> the choice of challenge values, which could be useful (e.g., for
> >>> differential cryptanalysis attack on the hash function), as the
> >>> attacker (client) already controls the nonce.
> >>>
> >>> As part of this, the server needs to check whether a challenge presented
> >>> on one connection or session has been reused on another.  I think the
> >>> following sentence in section 3 is intended to prevent this, but it's
> >>> weakened by the "stateless" language above:
> >>>
> >>>       The challenge MUST be
> >>>       unique for every HTTP 401 response in order to prevent replay
> >>>       attacks from passive observers.
> >>>
> >>> Explicit server checks for challenge reuse ought to be REQUIRED, and
> >>> the above use of "stateless" needs to be qualified.
> >>
> >> Hmm. I think that HOBA ought not REQUIRE full replay protection
> >> in all cases, that is, it SHOULD be possible to deploy a server
> >> that is vulnerable to some replay. The reason is that we're trying
> >> to displace passwords here and I believe (without much hard evidence
> >> I'll grant you) that we'd lose some deployment chances if we were
> >> to insist on every single challenge being fresh.
> >>
> >> So I'd argue for no-change here, but would welcome further discussionm
> >> evidence or suggestions for text that's not going to be so onerous
> >> as to weaken our chances of getting this deployed.
> >>
> >>
> >>>
> >>> [3] Web origin checks
> >>>
> >>> I did not see text mandating that TLS (server certificate), HTTP (accessed
> >>> URL) and HOBA (signature input) use the same web origin, and stating that
> >>> the server has to check/enforce this.  Did I miss something?
> >>>
> >>> I realize that this is an obvious requirement, but it does need to be
> >>> stated.
> >>
> >> Fair enough, I agree folks have been known to not implement even the
> >> most obvious things:-) I added the text below to section 3:
> >>
> >>    The server MUST check that the same web origin is used in all of the
> >>    server's TLS server certificate, the URL being accessed and the HOBA
> >>    signature.  If any of those checks fail, the server treats the
> >>    signature as being cryptographically incorrect.
> >>
> >>>
> >>> [4] TLS requirement level
> >>>
> >>> TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement -
> >>> first paragraph in Section 8.1 (Privacy Considerations).
> >>>
> >>> If TLS is not a "MUST" requirement, at least a discussion of man-in-the-
> >>> middle (MITM) attacks seems to be in order.  There's no need for an
> >> extensive
> >>> discussion of all of the security properties of TLS, but MITM attacks are
> >>> definitely worth a mention, and that could be complemented by a pointer to
> >>> suitable HTTP/TLS security considerations text elsewhere.
> >>
> >> I think that's covered where we note the potential for replay, which
> >> is what a MitM would/could do in this case. That is noted in both
> >> section 3 and in 6.1 and in section 8. I think we have it covered to
> >> be honest.
> >>
> >>>
> >>> [5] Section 5.3 - unrecognized key
> >>>
> >>> Paragraphs 4 and 5 in this section don't seem to belong here, and appear
> to
> >>> be written in a somewhat loose fashion, particularly around user
> >> verification.
> >>> A server that does what is suggested here could have significant security
> >>> weaknesses.
> >>
> >> Which specific weaknesses do you mean?
> >>
> >>>
> >>> I strongly recommend replacing those two paragraphs with a short sentence
> >> that
> >>> says:
> >>> 	- if a kid is unrecognized or the server otherwise determines
> >>> 		that the CPK is not to be used for this HTTP authentication,
> >>> 	- then the Registration (see 6.1) and/or Associating Additional Keys to
> >>> 		an Exiting Account (see 6.2) processes MAY be used instead of
> >>> 		treating this situation as an authentication failure.
> >>>
> >>> and moving all discussion of user verification into Sections 6.1 and 6.2.
> >>
> >> Sorry, I don't think that is needed at all. The current text simply
> >> reflects the kind of thing that we think deployments will do and will
> >> need to do and I don't see what specific weaknesses you are claiming
> >> might ensue. I'd be happy to note any such of course.
> >>
> >> Also, from my reading your suggested text has the same impact and
> >> only differs in using a 2119 MAY instead of could, might etc. But if
> >> you meant it to differ more substantively you'll need to explain that
> >> to me some more.
> >>
> >>>
> >>> -- Minor issues: --
> >>>
> >>> [A] ABNF encoding of alg
> >>>
> >>> In section 2, I see:
> >>>
> >>>    alg = 1*2DIGIT
> >>>
> >>>    o  alg: specifies the signature algorithm being used encoded as an
> >>>       ASCII character as defined in Section 9.3.
> >>>
> >>> Section 9.3 specifies a single digit.  How does that become 1*2DIGIT ?
> >>
> >> Huh? The current algs only use one digit, but the abnf allows for
> >> more. Nothing odd there that I can see.
> >>
> >>> I suggest: "as an ASCII character" -> "as one or two ASCII digits based
> >>> on the IANA registry established by Section 9.3"
> >>
> >> I think it's ok as is.
> >>
> >>> This may seem like a nit, but any imprecision in signature algorithm
> >>> input can lead to interoperability problems.
> >>
> >> Yes it can. But we're not being imprecise that I can see.
> >>
> >>>
> >>> [B] Section 5.3 - CPK vs. kid
> >>>
> >>>    In the authentication phase, the server extracts the CPK from the
> >>>    signing phase and decides if it recognizes the CPK.  If the server
> >>>    recognizes the CPK, the server may finish the client authentication
> >>>    process.
> >>>
> >>> That seems wrong.  IIUC, the HOBA client sends:
> >>>
> >>>    HOBA-RES = kid "." challenge "." nonce "." sig
> >>>
> >>> If so, I don't understand how the server extracts a CPK from that.
> >>
> >> Via the kid yes.
> >>
> >>>
> >>> I suspect that what was intended is that the server extracts a key
> >> identifier
> >>> (kid) and then determines a) whether it knows a CPK for that kid and b)
> >> whether
> >>> it allows use of that kid/CPK for this authentication.  At least a) seems
> to
> >>> be indicated by this text in Section 3:
> >>>
> >>>    The server MUST check the cryptographic correctness of the signature
> >>>    based on a public key it knows for the kid in the signatures,
> >>
> >> I'm not seeing an actionable issue that needs a change.
> >>
> >>>
> >>> [C] RSA signature algorithm
> >>>
> >>> Section 7 says:
> >>>
> >>>    RSA is defined in
> >>>    Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].
> >>>
> >>> Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5.  At a minimum, that
> >>> algorithm name should be stated here (which is a nit).
> >>
> >> Disagree (also as a nit:-)
> >>
> >>> The minor issue is
> >>> whether that is the signature algorithm that's wanted, on which I'll defer
> >>> to the crypto experts on that (e.g., I seem to recall a negative saag
> >>> comment on PKCS 1.5 mechanisms in the past couple of months).
> >>
> >> Yes, it's fine for security and is correct for interop/deployment
> >> reasons. PKCSv1.5 encryption is what's less desirable if not done
> >> well and attempting to mandate PSS here would be a bad plan.
> >>
> >>>
> >>> [D] Javascript local storage.
> >>>
> >>> The first paragraph of Section 8.2 on this topic concludes with:
> >>>
> >>>    It's not clear that we
> >>>    introduce unique threats from which clear text passwords don't
> >>>    already suffer.
> >>>
> >>> That's at odds with the use of "all" in this sentence in the abstract:
> >>>
> >>>    HOBA is an
> >>>    alternative to HTTP authentication schemes that require passwords and
> >>>    therefore avoids all problems related to passwords, such as leakage
> >>>    of server-side password databases.
> >>>
> >>> One of those two paragraphs needs some editing.
> >>
> >> I don't think so actually, the first quoted sentence above is in the
> >> context of a web site with XSS vulnerabilities. Omitting that context
> >> would make for bad text, but the immediately preceding sentence is
> >> fairly explicit on that.
> >>
> >> (In passing, I did edit the top of that para a bit, since using the
> >> WebCrypto API is now possible so a tweak was needed.)
> >>
> >>>
> >>> -- Nits/editorial comments: --
> >>>
> >>> This is buried near the end of section 6.1
> >>>
> >>>    Note that replay of registration (and other HOBA) messages is quite
> >>>    possible.  That however can be counteracted if challenge freshness is
> >>>    ensured.
> >>>
> >>> That's not a good place for these two sentences.  HOBA registration
> >>> messages don't contain a challenge, and the general discussion of
> >>> replay attacks belongs under Security Considerations, not Registration.
> >>
> >> They do contain a challenge in the header, though not in the body.
> >> I think the sentence is ok where it is.
> >>
> >>>
> >>> In Section 9.4 and 9.5, I see the following proposed as part of IANA
> >>> registry contents:
> >>>
> >>> 	an unformatted string, at the user's/UA's whim
> >>>
> >>> I get the point, but it's still not appropriate for an IANA registry
> >>> - remove ", at the user's/UA's whim".
> >>
> >> I whimsically disagree:-) IANA shouldn't be against whimsy.
> >>
> >>> Appendix A appears  to assume that human-memorable passwords are stored in
> >>> the clear in server databases.  It should also briefly discuss the use
> >>> of one-way functions, especially computationally intensive ones, to
> >>> generate stored password verifiers.  HOBA is still superior by comparison,
> >>> as the one-way functions only increase the difficulty of dictionary
> >>> attack, whereas dictionary attack on HOBA keys is pointless when
> >>> sufficiently large keys are used.
> >>
> >> I'd prefer to not get into more analysis of passwords, and even hashed
> >> passwords are essentially guessable.
> >>
> >>>
> >>> idnits 2.13.01 found the references to W3C's web site (www.w3.org) in
> >>> Section 4, e.g.,
> >>>
> >>> 389	   One element is required for HOBA-js: localStorage (see http://
> >>> 390	   www.w3.org/TR/webstorage/) from HTML5 can be used for
> persistent key
> >>> 391	   storage.
> >>>
> >>> I think idnits can be ignored, even though the "right way" to fix this is
> to
> >>> move each URL to a reference and cite the reference in Section 4.
> >>>
> >>> OTOH, idnits did not complain about the normative reference to RFC 20 ;-).
> >>
> >> Heh:-)
> >>
> >>>
> >>> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> >>>
> >>> Most of these questions are n/a because this draft describes an extension
> >>> to HTTP authentication, and RFC 5706's concerns would apply primarily to
> >>> HTTP and HTTP authentication.
> >>>
> >>> A.1.1    Has deployment been discussed?
> >>>
> >>> Yes, section 6 discusses how a user would deploy this for her access to
> web
> >>> servers.
> >>>
> >>> A.1.4.  Have the Requirements on other protocols and functional
> >>>        components been discussed?
> >>>
> >>> Yes, the discussion of how this functions within HTTP is sufficient.
> >>>
> >>> Major issues [3] and [4] fall into this category, but in both cases,
> >>> I think they're probably text oversights that are easy to fix.
> >>>
> >>> A.2.7 Is security management discussed?
> >>>
> >>> Not really, but this is an Experimental RFC.  I would expect that the
> >>> experimental use of HOBA will yield insight into server key database
> >>> structure/management, key lifecycle management (e.g., revocation),
> >>> account management techniques/processes, etc.
> >>>
> >>> A.3.  Documentation
> >>>
> >>> I do not expect significant operational impact.
> >>>
> >>> Section 10 notes the existence of two implementations of HOBA-JS and
> >>> one implementation of HOBA-http.  That's a good start for an experiment.
> >>
> >> And now there's a 3rd!
> >>
> >> Thanks again for the fine review,
> >> S.
> >>
> >>
> >>>
> >>> Thanks,
> >>> --David
> >>> ----------------------------------------------------
> >>> David L. Black, Distinguished Engineer
> >>> EMC Corporation, 176 South St., Hopkinton, MA  01748
> >>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> >>> david.black@xxxxxxx        Mobile: +1 (978) 394-7754
> >>> ----------------------------------------------------
> >>>
> >>>
> >>>




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]