Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00

["Joel M. Halpern" <[e-mail]>]

My understanding matches Alia's.  It is an opaque string recorded for 
traceability.  In particular, to allow the broker model the attribution 
has to be per-request.

Yours,
Joel

On 6/23/15 9:41 AM, DIEGO LOPEZ GARCIA wrote:
> Hi Alia,
>
> My understanding was that secondary identity was not intended to be only
> a general declaration made by the client, in which case what you say
> definitely holds. If the trust model at the agent does not completely
> rely on client assertions, the only way in which I see you can ensure
> traceability is by associating data with a minimum level of assurance,
> in despite of those data being opaque or not to the entities providing
> or recording them.
>
> If the first assumption holds, I'll stay corrected and support your
> comment to section 3.1. If not, I'd say I have a point here...
>
> Be goode,
>
> On 23 Jun 2015, at 14:10 , Alia Atlas <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>> Hi Diego,
>>
>> The secondary identity is just an opaque value to allow traceability.
>> It's to support a
>> client easily being a broker for multiple applications.  I don't agree
>> that there is value
>> in trying to secure the secondary identity the way you are
>> describing.  This path leads
>> to there being basically no value for having secondary identities.
>>
>> Regards,
>> Alia
>>
>> On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>
>>     --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
>>     Content-Transfer-Encoding: quoted-printable
>>     Content-Type: text/plain;
>>             charset=us-ascii
>>
>>     Hi Alia,
>>
>>     Just a remark on your comment about section 3.1: I think the current =
>>     requirement of associating a single secondary identity per
>>     connection =
>>     does make sense if we want to keep traceability over I2RS secure =
>>     transports.=20
>>
>>     You need to associate secondary identities with primary ones in a
>>     secure =
>>     way to guarantee such traceability, and the mechanisms for this I
>>     can =
>>     imagine using current transports (such as a certificate extension or =
>>     alternate identity, or additional information in secure tokens) are =
>>     associated with connection handshake, and therefore re-association
>>     is =
>>     complicated to implement without restarting the connection. Note I
>>     say =
>>     complicated, not impossible, but I cannot see the advantage in the =
>>     additional complexity, especially when experience shows that
>>     additional =
>>     complexity becoming source of security flaws...
>>
>>     Be goode,
>>
>>     On 11 Jun 2015, at 22:11 , Alia Atlas <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>     > <no-hat>
>>     >=20
>>     > Sue,
>>     >=20
>>     > Thanks for writing this draft.  I think it is useful to clearly =
>>     articulate the outside-of-I2RS behavior and protocols that are
>>     needed =
>>     for the mutual authentication.  I do have a couple comments on the =
>>     draft.
>>     >=20
>>     >=20
>>     > In Sec 3.1, it says "Each Identity will be linked to one secondary =
>>     identity for the period of a connection."  I would have assumed
>>     that the =
>>     client could arbitrarily change its' secondary identity.  This is to =
>>     support the broker case where a client may be passing along requests =
>>     from multiple applications.  Since the secondary identity is just
>>     passed =
>>     along and stored for traceability, I don't think that allowing it to =
>>     change would cause significant complications.   What do others think?
>>     >=20
>>     >=20
>>     > In the I2RS architecture, there are 3 different types of
>>     transaction =
>>     behavior desired for processing a message. In Sec 4, there's an =
>>     assumption that "fail-on-error" with the associated roll-back is the =
>>     only mode.   Thus, I think that Section 4 needs a bit of massaging.
>>     >=20
>>     >=20
>>     > Thanks,
>>     >=20
>>     > Alia
>>     > _______________________________________________
>>     > i2rs mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/i2rs
>>
>>     --
>>     "Esta vez no fallaremos, Doctor Infierno"
>>
>>     Dr Diego R. Lopez
>>     Telefonica I+D
>>     http://people.tid.es/diego.lopez/
>>
>>     e-mail: [e-mail]
>>     <mailto:[e-mail]>
>>     Tel: [phone] <tel:%2B34%20913%20129%20041>
>>     Mobile: [phone] <tel:%2B34%20682%20051%20091>
>>     ----------------------------------
>>
>>
>>     --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
>>     Content-Transfer-Encoding: quoted-printable
>>     Content-Type: text/html;
>>             charset=us-ascii
>>
>>     <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
>>     charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
>>     -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi =
>>     Alia,<div><br></div><div>Just a remark on your comment about section =
>>     3.1: I think the current requirement of associating a single
>>     secondary =
>>     identity per connection does make sense if we want to keep
>>     traceability =
>>     over I2RS secure transports.&nbsp;</div><div><br></div><div>You
>>     need to =
>>     associate secondary identities with primary ones in a secure way to =
>>     guarantee such traceability, and the mechanisms for this I can
>>     imagine =
>>     using current transports (such as a certificate extension or
>>     alternate =
>>     identity, or additional information in secure tokens) are associated =
>>     with connection handshake, and therefore re-association is
>>     complicated =
>>     to implement without restarting the connection. Note I say
>>     complicated, =
>>     not impossible, but I cannot see the advantage in the additional =
>>     complexity, especially when experience shows that additional
>>     complexity =
>>     becoming source of security flaws...</div><div><br></div><div>Be =
>>     goode,</div><div><br><div><div>On 11 Jun 2015, at 22:11 , Alia Atlas =
>>     &lt;<a href=3D"mailto:[e-mail]
>>     <mailto:[e-mail]>">[e-mail]
>>     <mailto:[e-mail]></a>&gt; =
>>     wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
>>     type=3D"cite"><meta http-equiv=3D"Content-Type"
>>     content=3D"text/html; =
>>     charset=3Dutf-8"><div
>>     dir=3D"ltr">&lt;no-hat&gt;<br><br>Sue,<br><br>Thanks=
>>      for writing this draft.&nbsp; I think it is useful to clearly =
>>     articulate the outside-of-I2RS behavior and protocols that are
>>     needed =
>>     for the mutual authentication.&nbsp; I do have a couple comments
>>     on the =
>>     draft.<br><br><br>In Sec 3.1, it says "Each Identity will be
>>     linked to =
>>     one secondary identity for the period of a connection." &nbsp;I
>>     would =
>>     have assumed that the client could arbitrarily change its' secondary =
>>     identity.&nbsp; This is to support the broker case where a client
>>     may be =
>>     passing along requests from multiple applications.&nbsp; Since the =
>>     secondary identity is just passed along and stored for
>>     traceability, I =
>>     don't think that allowing it to change would cause significant =
>>     complications. &nbsp; What do others think?<br><br><br>In the I2RS =
>>     architecture, there are 3 different types of transaction behavior =
>>     desired for processing a message. In Sec 4, there's an assumption
>>     that =
>>     "fail-on-error" with the associated roll-back is the only mode.
>>     &nbsp; =
>>     Thus, I think that Section 4 needs a bit of =
>>     massaging.<br><br><br>Thanks,<br><br>Alia</div>
>>     _______________________________________________<br>i2rs mailing =
>>     list<br><a =
>>     href=3D"mailto:[e-mail] <mailto:[e-mail]>">[e-mail]
>>     <mailto:[e-mail]></a><br>https://www.ietf.org/ma=
>>     ilman/listinfo/i2rs
>>     <https://www.ietf.org/ma=ilman/listinfo/i2rs><br></blockquote></div><br><div
>>     =
>>     apple-content-edited=3D"true">
>>     <div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: =
>>     auto; text-align: start; text-indent: 0px; text-transform: none; =
>>     white-space: normal; widows: auto; word-spacing: 0px; =
>>     -webkit-text-stroke-width: 0px; word-wrap: break-word; =
>>     -webkit-nbsp-mode: space; -webkit-line-break: =
>>     after-white-space;">--<br>"Esta vez no fallaremos, Doctor =
>>     Infierno"<br><br>Dr Diego R. Lopez<br>Telefonica I+D<br><a =
>>     href=3D"http://people.tid.es/diego.lopez/">http://people.tid.es/diego.lope=
>>     z/ <http://people.tid.es/diego.lope=z/></a><br><br>e-mail:
>>     [e-mail]
>>     <mailto:[e-mail]><br>Tel: &nbsp; =
>>     &nbsp;[phone] <tel:%2B34%20913%20129%20041><br>Mobile: +34
>>     682 051 =
>>     091<br>----------------------------------</div>
>>
>>     </div>
>>     <br></div></body></html>=
>>
>>     --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1--
>>
>>     ________________________________
>>
>>     Este mensaje y sus adjuntos se dirigen exclusivamente a su
>>     destinatario, puede contener información privilegiada o
>>     confidencial y es para uso exclusivo de la persona o entidad de
>>     destino. Si no es usted. el destinatario indicado, queda
>>     notificado de que la lectura, utilización, divulgación y/o copia
>>     sin autorización puede estar prohibida en virtud de la legislación
>>     vigente. Si ha recibido este mensaje por error, le rogamos que nos
>>     lo comunique inmediatamente por esta misma vía y proceda a su
>>     destrucción.
>>
>>     The information contained in this transmission is privileged and
>>     confidential information intended only for the use of the
>>     individual or entity named above. If the reader of this message is
>>     not the intended recipient, you are hereby notified that any
>>     dissemination, distribution or copying of this communication is
>>     strictly prohibited. If you have received this transmission in
>>     error, do not read it. Please immediately reply to the sender that
>>     you have received this communication in error and then delete it.
>>
>>     Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>>     destinatário, pode conter informação privilegiada ou confidencial
>>     e é para uso exclusivo da pessoa ou entidade de destino. Se não é
>>     vossa senhoria o destinatário indicado, fica notificado de que a
>>     leitura, utilização, divulgação e/ou cópia sem autorização pode
>>     estar proibida em virtude da legislação vigente. Se recebeu esta
>>     mensagem por erro, rogamos-lhe que nos o comunique imediatamente
>>     por esta mesma via e proceda a sua destruição
>>
>>
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: [e-mail]
> Tel:    [phone]
> Mobile: [phone]
> ----------------------------------
>
>
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud
> de la legislación vigente. Si ha recibido este mensaje por error, le
> rogamos que nos lo comunique inmediatamente por esta misma vía y proceda
> a su destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited. If you have
> received this transmission in error, do not read it. Please immediately
> reply to the sender that you have received this communication in error
> and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida em
> virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição
>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>