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

From: Alia Atlas <[email-masked]>
Date: Thu, 11 Jun 2015 16:11:38 -0400

<no-hat>

Sue,

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.

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?

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.

Thanks,

Alia

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 23 Jun 2015 13:02:34 +0000

--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 <[email-masked]> 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
> [email-masked]
> 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: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

--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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a><br>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/</a><br><br>e-mail: [email-masked]<br>Tel: &nbsp; =
&nbsp;+34 913 129 041<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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Jun 2015 09:10:56 -0400

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 <
[email-masked]> wrote:

> 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
>

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 23 Jun 2015 13:11:23 +0000

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.

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 <[email-masked]<mailto:[email-masked]>> wrote:

<no-hat>

Sue,

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.

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?

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.

Thanks,

Alia
_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

Dr Diego R. Lopez
Telefonica I+D

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 23 Jun 2015 13:41:00 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alia,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041<tel:%2B34%20913%20129%20041>
Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091>
----------------------------------

&lt;<a href=3D"mailto:[email-masked]<mailto:[email-masked]>">[email-masked]<mailto:[email-masked]></a>&gt; =
href=3D"mailto:[email-masked]<mailto:[email-masked]>">[email-masked]<mailto:[email-masked]></a><br>https://www.ietf.org/ma=
ilman/listinfo/i2rs<https://www.ietf.org/ma=ilman/listinfo/i2rs><br></blockquote></div><br><div =
z/<http://people.tid.es/diego.lope=z/></a><br><br>e-mail: [email-masked]<mailto:[email-masked]><br>Tel: &nbsp; =
&nbsp;+34 913 129 041<tel:%2B34%20913%20129%20041><br>Mobile: +34 682 051 =

</div>

Dr Diego R. Lopez
Telefonica I+D

---

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Jun 2015 10:20:34 -0400

Hi Diego,
On Jun 23, 2015 9:41 AM, "DIEGO LOPEZ GARCIA" <[email-masked]>
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.
>
>
I believe that the secondary identity is intended to be only a general
declaration made by the client.  It's the minimum to provide some
traceability without complicated support for the broker client model.  That
is why it is merely an opaque value to the agent; it has no meaning and
isn't verified but merely stored.

With the primary identity verified and an integrity-protected channel for
writing state, I think that secondary identity will be whatever the
associated client sent.  By having that opaque value recorded, an operator
can compare it to what the client thinks was happening.

Certainly, that's the discussion and conclusion that I recall and I haven't
seen any further discussion to make me think that the conclusion has
changed.

Regards,
Alia

>  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 <[email-masked]> wrote:
>
>  Hi Diego,
>
>> charset=3Dutf-8"><div
>> dir=3D"ltr">&lt;no-hat&gt;<br><br>Sue,<br><br>Thanks=
>> ilman/listinfo/i2rs <https://www.ietf.org/ma=ilman/listinfo/i2rs><br></blockquote></div><br><div
>> =
>> z/ <http://people.tid.es/diego.lope=z/></a><br><br>e-mail:
>> [email-masked]<br>Tel: &nbsp; =
>> 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
>>
>
>
>  --
> ------------------------------
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Jun 2015 17:48:00 -0400

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:
> 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.
>
>> On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>
>>     > [email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked]>
>>     Tel: +34 913 129 041 <tel:%2B34%20913%20129%20041>
>>     Mobile: +34 682 051 091 <tel:%2B34%20682%20051%20091>
>>     &lt;<a href=3D"mailto:[email-masked]
>>     <mailto:[email-masked]>">[email-masked]
>>     <mailto:[email-masked]></a>&gt; =
>>     href=3D"mailto:[email-masked] <mailto:[email-masked]>">[email-masked]
>>     <mailto:[email-masked]></a><br>https://www.ietf.org/ma=
>>     ilman/listinfo/i2rs
>>     <https://www.ietf.org/ma=ilman/listinfo/i2rs><br></blockquote></div><br><div
>>     =
>>     [email-masked]
>>     <mailto:[email-masked]><br>Tel: &nbsp; =
>>     &nbsp;+34 913 129 041 <tel:%2B34%20913%20129%20041><br>Mobile: +34
>>     682 051 =
>>     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.
>>
>>     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.
>>
>>     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
>>
>>
>
> --
> ------------------------------------------------------------------------
>
> 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.
>
> 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.
>
> 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
>
>