Soma,
On Jul 13, 2014, at 11:10 PM, Soma Meiyappan <Soma.Meiyappan at conexant.com> wrote:
> ...
> 4. This could be a topic for the implementer’s guide; but can be addressed in the specification too: While we are mostly not concerned about products that choose the most secure channel for communicating with the device, we may want to briefly touch vulnerability as the stakes are higher with new operation attributes related to credentials to access third party services have been introduced in IPP Scan. Further since these may not be sufficiently covered by the security considerations of RFC2911, it may be safer to discuss the vulnerability aspect of these, just in case it is not obvious to the implementers. We could do one of the three below. Only 4.a is a secure method. 4.b is sufficiently addresses security of credentials if the client is properly implemented and if certification processes ensure that. 4.c is purely a warning to the developer.
> a. By specification, make encryption (IPPS) mandatory for Scan (either always or at least, if credentials are required): I know that this is a little heavy handed and may not be well liked; but ‘IPP Scan’ does not have any legacy support to worry about.
> b. Advertise those destination-uri that REQUIREs credentials only if the request came in through a secure channel (https or USB) and not if the request came through an unsecure channel (http and not USB). One implementation concern here is some web-servers may not convey information about the secureness of the channel to the application layer; but not something insurmountable. This also means that unsecure IPP will be a reduced function set compared to the secure IPPS. While this duality may make some uncomfortable, this is a very pragmatic way to keep user information safe.
> c. Make comments about the vulnerability in exposing credentials through IPP (instead of IPPS)
We definitely need to say something about this in the security considerations; requiring the use of TLS (IPPS or IPP with HTTP Upgrade) is probably the way to go.
> ...
> Proposal for new attributes to destination-uri-ready
>> If destination-uri-ready can take additional member attributes to allow the system to specify the OAuth URL that the scan client needs to contact and the auth scope that the authorisation should be requested for, the scan client may be able to try to start the OAuth2 flow by connecting to the OAuth URL (and specifying the auth scope in the process), finish the OAuth2 process and get the OAuth2 access token for accessing the service that the device wants the access token for. For that, I would like to propose an optional attribute that is part of a destination-uri-ready.
>> destination-uri-ready
> destination-uri
> . . .
> [destination-oauth-descriptor (collection)]
> [destination-oauth-uri (uri)]
> destination-oauth-scope (1setOf text(MAX))
I think I'd rather make these optional top-level member attributes - drop the destination-oauth-descriptor collection, put them directly under the destination-uri-ready collection. As for the scope, you probably want "1setOf octetString(MAX)" since text implies a localized string value.
We'll also need something similar for the System Control Service spec, since that will be expanding our support for OAuth and delegated access control/credentials.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140714/aa2f2c79/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140714/aa2f2c79/attachment.p7s>