From: Ludwig Seitz <ludwig@sics.se>
To: ace@ietf.org
References: <CAD2CPUFJi7QizdOwPOtkTd21VRREjarD+tvwmM0sN9h=Qy-+Yw@mail.gmail.com>
Message-ID: <578D01F1.9040909@sics.se>
Date: Mon, 18 Jul 2016 18:21:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CAD2CPUFJi7QizdOwPOtkTd21VRREjarD+tvwmM0sN9h=Qy-+Yw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="------------ms050805050505030608050800"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/xBM_aDNUTNatIMWGvrxJmFOhWyk>
Subject: Re: [Ace] review draft-ietf-ace-oauth-authz-02
Precedence: list

This is a cryptographically signed message in MIME format.

--------------ms050805050505030608050800
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 2016-07-08 17:04, Renzo Navas wrote:
> Hi ace wg,
> Hi Ludwig, G=C3=B6ran, et al.
>
~snip~

Thank you Renzo for taking the time to do this review. Please find my=20
comments inline.

Regards,

Ludwig

>
> ----------------------------------------------------------------
> Review of https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02
> ---------------------------------------------------------------
>
> 4. Protocol Interactions
> "The consent of the resource owner, for giving a client access to a
> protected resource, can be pre-configured authorization policies or
> dynamically at the time when the request is sent."
>
> "when the request is sent": The request we are talking is the Resource
> Request (Client already has the access token) or the token request? I
> believe is Resource Request.
> would it be good to explicit where this authz. policies are
> pre-configured (at the AS? were enforced before at the token request
> and are now embedded on the Access token; or at the RS?);
> and how the consent can be dynamically determined (will involve
> interaction with the Res Owner : RS to RO; RS to AS to RO ?).
> All this is out of scope of the draft, however I believe making
> explicit at least where the authz policies are pre-conf can be a good
> idea, just a suggestion.
> (My understanding is that they are at the AS; and were enforced at the
> token request; if introspection is used, can be enforced again at the
> resource request).
>

Sorry this is a case of bad word-choice by me. The idea is of course=20
that the AS determines the consent of the RO at the time of the access=20
token request (i.e. C -> AS). This can be either done by asking the RO=20
or by using authorization policies defined by the RO previously at the=20
AS. I'm adding an issue about this.


> 4. Messages Flows description: A-F:
> Would it be too redundant to state which security properties needs
> each messages, or it will be clearer? (A,B,D,E,F encrypted+integrity
> protected. C does not)
> This is just a question/suggestion; each message sec. requ. are stated
> in other parts of the draft (early on section 4, and on section 5 and
> 6...).
>

This could depend on the profiles, e.g. message B could need to be=20
encrypted (if a symmetric PoP key is transferred) or just integrity=20
protected (if a asymmetric PoP key is used). Therefore I'd rather not=20
make these kind of statements here.

>
> 5.  Framework
> Proof-of-Possession
> FROM           " i.e. that the authenticated token holder is bound to
> the token."
> to Something like " i.e. that the token holder can prove being a
> holder of the key bound to the token"
>

Sounds good.


>
> 5.  Framework
> "In OAuth 2.0 the communication with the Token and the Introspection
> resources at the AS (...) This framework RECOMMENDS to use CoAP instead=
 and
> RECOMMENDS the use of the following alternative instead of Uri-query
> parameters: The sender (client or RS) encodes the parameters of its
> request as a CBOR map and submits that map as the payload of the POST
> request.  The Content-format MUST be "application/cbor" in that case."
>
> If we use plain cbor on top of coap this means we are using dtls  to
> protect the messages.
>
> If we are protecting the messages with cose, should we not use the
> Content-Format: "application/cose;cose-type=3Dcose-encrypt" ?
>
> All the examples of the doc use appplication/cbor; however, can be
> useful to mention somewhere (here?) that if cose is used the content
> format is "application/cose"?
>

Correct, if we add other security wrappers around the data we may need=20
to change the Content-format. I'll add an issue about this.


>
> ----------------------
> 6.  The 'Token' Resource
> "Communication between the client and the token resource at the AS
> MUST be integrity protected and encrypted.  Furthermore AS and client
> MUST perform mutual authentication. Profiles of this framework are
> expected to specify how authentication and communication security is
> implemented."
>
> Is it worthy (.. is it accurate?) to express that the Token Request,
> from C to AS might not be source-authenticated, and the AS -in that
> case- can authenticate the request ("a posteriori") with the
> client_id/client_secret?
> The buzz in my head came because authentication of the client can be
> done at dtls/cose level (that, for me, its not a must), and also with
> the client credentials inside the request.
> I think that the description on the text is generic enough so any
> interpretation of how to authenticate the C towards AS, is OK.
> In any case I send to you this (confusing) thoughts I had when I first
> read this sentence. Authentication can be done at communication level
> with the PSK C-AS , and also with the client_secret (maybe this is an
> "application authentication"...).
>
>
You are right, we should clarify these options ... creating an issue


>
> 6.  The 'Token' Resource
> "The figures of this section uses CBOR diagnostic notation without the
> integer abbreviations for the parameters or their values for better
> readability."
> (already did this comment) is worth mentioning that if cose is used,
> the coap messages content-type are application/cose, and we show the
> cbor plaintext payload?
>

Yes that was the intention of these examples. I'll check if that needs=20
clarification.

> -------------------
>
>
> 6.1.  Client-to-AS Request
> Figure 3: Example request for an access token bound to an asymmetric ke=
y.
> "grant_type" : "token"
>
> I have not found the definition of grant_type "token" , should not be
> "client_credentials"? (
> https://tools.ietf.org/html/rfc6749#section-4.4.2 )
>

Good catch! I think that was just an error.

> ------------
> 6.2.  AS-to-Client Response
> Figure 5: Example AS response with an access token bound to a symmetric=
 key.
> "{ "access_token" : b64'SlAV32hkKG ...
>        (...),
>       "token_type" : "pop",
>       "alg" : "HS256",
>       "cnf" : {
>         "COSE_Key" : { ...."
>
> how does the "alg" field of the token response relates to the
> "key_alg" from the COSE_Key object if present, they must match , or
> cose_key alg must be a super-set of this "alg"?
> In 6.4.2 this "alg" is defined, Now that I read the passage
> attentively, this "alg" field in the token response is only used for
> the initial PoP; then the key can be used with other algorithms (e.g.
> to encrypt with aes-ccm). OK.
> I left this comment to show the confusion that produced the "alg"
> field at two different levels, maybe its worthy to briefly tell the
> difference/purpose of each one in contrast to each other.
> ------------

The intention is of course that 'alg' is used to identify the initial=20
PoP procedure, this may include generating further keys for=20
communication security. Obviously the key_alg parameter, if present,=20
should identify the same algorithm as the alg parameter.

I'll add an issue to clarify this.


>
> 6.4.4.  Confirmation
>
> "COSE_Encrypted  In this case the 'cnf' parameter contains an
> encrypted symmetriic key destined for the client."
> (typo "symmetriic").

Noted.

> Is it needed to encrypt the symmetric key inside cnf?

If the channel is not secure this would be necessary. Otherwise you can=20
just use a COSE_Key inside 'cnf'

> Was not assumed that the communication between AS and Client was
> already protected (the whole response was integrity protected and
> encrypted).
> Or it was a general statement, and this is a particular case? In any
> case, fields outside cnf should be at least integrity protected.
>

It might be the case that this is not really needed. I'll go through the =

use cases and check. This comes from the fact that we copied the=20
properties of the 'cnf' parameter form RFC7800, which includes an=20
encrypted key.

>
> GENERAL OBSERVATION (already did on section 4): Can be a good idea to
> specify for each message which kind of security properties
> (confidentiality, integrity/data authentication)'
> we need and at what level/layer (e.g: transport layer/application
> layer, Cose_key field needs confidentiality but the rest only
> integrity, etc.)?
>
I think that depends on the specific contents of the message, so I'm not =

sure if it can be said generally for each message.



> -----------
>
> 7.  The 'Introspect' Resource
> " Finally the AS SHOULD to verify that the RS"
> remove/"to" ?
> ------------
>
Noted


>
> 7.4.  Client Token
>
> Personally I believe this is a very relevant use case.
> This "client token" solution is elegant, and easy to understand on the
> context on the rest of the framework.
>
> ------------
>
> 8.2.  Token Expiration
> "RS verifies these by comparing them to values from its internal clock
> as defined in [RFC7519].
> In this case the RS must have a real time chip (RTC) or some other ..."=

> Shall it say "real time clock (RTC)"?
> Its worthy to be more clear and say that the internal clock should
> reflect the current date/time, or at least be synchronized with the
> issuer-of-the-token's clock (the AS)?
>

I'll clarify this.

> ----------------------
>
> Appendix C.  Deployment Examples
>
> Comment: I found it VERY useful to see the real exchange of messages.
>
>
> C.1.  Local Token Validation
> " The token includes the claim "aif" with the authorized
>    access that an owner of the temperature device can enjoy.  The
>    'aif' claim, issued by the AS, informs the RS that the owner of
>    the token, that can prove the possession of a key is authorized to"
>
> The first sentence should not say: ".. that an owner of the of the
> token, that can prove the possession of a key can enjoy" instead of
> the "owner of the temperature device" ?
>

Sorry all the examples in the appendices are not up to date, we intended =

to remove the 'aif' claim from this document for the time being and=20
missed this section.

>
> C.1. Local Token Validation
>
> About "AIF" claim
>
> should not reference
> https://tools.ietf.org/html/draft-bormann-core-ace-aif-03 somewhere?
>
> "aif" claim is only mentioned on appendix C, what happened on the rest
> of the document? (is not a valid claim?)
> In cbor web token
> (https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-00#appendix-=
A.3
> ) , the only reference of aif is on Appendix 3!
> shall we give more visibility for the aif claim on the main body of the=
 doc?
>

See comment above.

> --------------------------------------------
>
> C.2.  Introspection Aided Token Validation
>
> "Figure 23: Request and Response Payload for C offline"
> "COSE_Key" : {
>           "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
>           "kty" : "oct",
>           "alg" : "HS256",
> "
>
> * Should not be: "kty": "Symmetric " ?

I'll check that.

>
> * "alg", supossedly this is key_alg that specifies "Key usage
> restriction to this algorithm".
> "HS256", I found a reference on json web token, and says "indicates
> that this token is signed using HMAC-SHA256."
> Should not be put on "alg" the algorithm that will be used on the
> DTLS-PSK performed later? e.g.: "AES-CCM-16-64-128"?

This is actually not quite clear in the COSE draft. Table 3 suggests the =

parameter should be called 'alg' not 'key_alg'. I'll ask for=20
clarification by Jim Schaad.

I think this example needs to be updated as well, it seems broken.


> ------------------------------
>
> "E: The AS provides the introspection response containing
>   (...). (...) allows the RS to verify the client's proof of
> possession in step F.
> After receiving message E, the RS responds to the client's POST in
> step C with Code 2.01 Created."
>
> See "Figure 24: Token Introspection for C offline"
>
> "step C with Code 2.01 Created", Is this not the "Step F"?
>

Yes this figure is not aligned with the steps in figure 1. I'll fix that.=


>
> -------------
> Both comments coming from "Figure 25: Request and Response Payload for
> Introspection:"
>
> "Request-Payload:
> ...
>    "client_id" : "FrontDoor",
>    "client_secret" : "ytrewq"
> "
>
> This is introspection request from RS to AS.
> How did the RS got the client_id and the client_secret? (previous,
> message from C to RS is not protected)
>

Good catch, all these examples in the appendices need to be looked over=20
I think.

>
> "Response-Payload:
> ...
> "cnf" : {
>         "kid" : b64'...'}
> "
> Should not "cnf" need to have the whole "COSE_Key" (including "k")?
> On the text it was not assumed that RS and C already shared a Key (if
> they did, at some point after original C-AS request, AS must have
> provisioned it to RS -this can be assumed-).
> In the general case AS will have to transport the key to RS on the
> introspection response I think
>
You are right there as well.




--=20
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelev=C3=A4gen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se



--------------ms050805050505030608050800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3
aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF
B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK
/swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji
/GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0
+jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y
z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84
MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v
YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug
KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB
Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG
BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF
KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D
I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f
qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd
vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6
V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw
DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT
IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw
MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn
BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy
dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt
TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf
a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx
7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D
IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg
MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T
AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv
bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z
dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz
L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv
GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB
i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB
OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets
D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI
NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA
0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf
1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/
tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH
2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9
VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp
/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa
otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0xNjA3MTgxNjIxMDVaMC8GCSqGSIb3DQEJBDEiBCBOGxZz4s61
kQOD/T4iVt5t93374t5tber8ShtCE0FSgzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB
KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu
dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD
QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQA1jMHyD4zi+KQJaQ5q2fTD
+xfrYCwWRh3Wgtjb4EsT/ht5die+yBWBwIU5MnPjrJEnr2pc8P7lRTSNw4P89iIk3TD6lqBL
y308LuM0g3HqKEec5smrXR4bEFGx2WEqBfTRVZtYHKK3FWTuIrxbnvTClX5iPRnPmvMjGWJ0
IUPS78Kdmd3djSn/nehKgd/KPol9zW7S2eEwpC9SZOTaFo7L7HBepgkeu3ycHL4yvh+mjyn0
KOVI4m/dFU4qhUNIC/NKXNH9+Dxj5Vx9Mw1TQVQlyP2LK8g7CV5IJsdaOFoskL6nyAWYf1tB
Whn2fLS39X3mzAhbIEU2/eYr0h5deq/fAAAAAAAA
--------------ms050805050505030608050800--