Subject: [Sipping] Working Group Last Call -- draft-ietf-sipping-nai-r eqs

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Fri, 7 Jun 2002 16:59:20 -0400

Section 7 refers ... the mechanism of 3.2 ... 3.1....
 
There are no subsections like 3.2 or 3.1. Are those 4.2 and 4.3 instead?

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 10 Jun 2002 10:04:53 +0100

Yes. Next version will be based on XML source, so the references will fix
themselves.
 
...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 10 Jun 2002 10:11:44 +0100

Yes. It is the human beings who construct the Trust Domain who know that
*all* nodes in the Trust Domain conform to Spec(T). They decide how much of
that knowledge to configure into the devices in the Trust Domain. We do not
require that every node in the Domain 'knows' about every other node, though
you could certainly configure your nodes this way if you wanted to.

This addresses an important problem with the earlier identity work, where
the term 'trusted' was thown about rather liberally. Now we are being sure
to state that for things to work, the node you are corresponding with not
only has to be compliant to Spec(T), but you have to know this fact (by
configuration) and have a secure connection (integrity, confidentiality).

...Mark

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 09 June 2002 06:37
> To: Michael Hammer
> Cc: Watson, Mark [MDN05:EP10:EXCH]; 'Dean Willis'; [email-masked]';
> [email-masked]'; 'Jon Peterson ([email-masked])';
> [email-masked]'
> Subject: Re: [Sipping] Working Group Last Call --
> draft-ietf-sipping-nai-r eqs
> 
> 
> 
> 
> Michael Hammer wrote:
> > Based on this definition and my previous comment regarding the 
> > diagram.  Does spec(T) also require that there be a secure 
> connection 
> > between the two elements?
> > 
> > I understood the dotted line meant all parties were in the 
> same trust
> > domain.
> > Being in the same trust domain means that all parties share the same
> > spec(T).
> > Sharing the same spec(T) means that A, B, and C can 
> mutually trust each
> > other.
> > 
> > The previous response said no.  What am I missing?
> 
> Sharing spec(T) does not mean A,B, and C can mutually trust 
> each other. 
> In the diagram, A cannot trust C. Even though it knows C conforms to 
> Spec(T), it doesn't have a secure connection to C, and 
> therefore, can't 
> be sure that the thing its talking to is C, and so doesn't 
> know for sure 
> that it follows spec(T).
> 
> -Jonathan R.
> 
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
>

---

From: Michael Hammer <[email-masked]>
Date: Mon, 10 Jun 2002 12:29:36 -0400

Mark,

So this is "by definition" rather than an assessment based on knowledge of 
a particular situation.  Seeing as this definition results in a stronger 
"trust" model, I need only to accept the definition.

Thanks, I understand now.

Mike

At 10:11 AM 6/10/2002 +0100, Mark Watson wrote:

>*all* nodes in the Trust Domain conform to Spec(T). They decide how much 
>of that knowledge to configure into the devices in the Trust Domain. We do 
>not require that every node in the Domain 'knows' about every other node, 
>though you could certainly configure your nodes this way if you wanted to.
>
> > From: Jonathan Rosenberg 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: 09 June 2002 06:37
> > To: Michael Hammer
> <http://www.jdrosen.net>http://www.jdrosen.net                  PH: 
> (973) 952-5000
> > <http://www.dynamicsoft.com>http://www.dynamicsoft.com
> >
> >

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 10 Jun 2002 17:37:25 +0100

> 
> So, I guess I need to read a couple things into the picture:
> 
> 1)  Spec(T) conformance cannot define behavior at B such that 
> transitive 
> trust between A and C could be established.
> 

Well, this is not exactly what is intended. Spec(T) describes behaviour at B
which enables devices which trust B to trust in the authenticity of the
Network Asserted Identity information they receive from B.

More exactly, Spec(T) says that there are only two ways that Network
Asserted Identity information can be obtained by B:
(i) by following some known authentication process, say Aut(T), or
(ii) by receiving the information from another node which is known to follow
Spec(T)

So, A can know that the information it receives from B was originally
generated using the process Aut(T), but it does not know (or care) which
particular node used Aut(T) to do it - it might have been C.

So, it is an assumption that the reliability of the process Aut(T) is
independent of the node that it is executed on - this too needs to be a
requirement of Spec(T).

The whole definition is 'for the purposes of Network Asserted Identity' - so
we define 'trust' only in terms of the implications for NAI. It would have
been more accurate to talk about 'NAI-trust' and 'NAI-Trust-Domains'. This
was in response to comments that generalised 'transitive trust' was
dangerous ground.

> 2) There is an assumption that C cannot authenticate itself 
> and sign a 
> message that is passed through B over the secure connections 
> to A.  (In 
> other words, that would be represented by an additional 
> secure connection 
> line from A to C.
> 

The diagram is just an example, and, although we didn't consider this case,
if (i) it were possible for C to sign a message and send it through B to A
and (ii) A had configuration knowledge that C was a member of the trust
domain, then I suppose this is indeed equivalent to a secure connection
between A and C in the terms of the definition. I can't see that this causes
a problem.

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Mon, 10 Jun 2002 13:25:34 -0400

I would request to include the clarifications (e.g., NAI-trust, NAI-trust-domain, definitions of Spec(T), brief examples as provided below) in the "NAI requirement" document. Accordingly, the SIP extensions document will complement the solution.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, June 10, 2002 12:37 PM
To: 'Michael Hammer'; Jonathan Rosenberg
Cc: 'Dean Willis'; [email-masked]'; [email-masked]'; 'Jon Peterson ([email-masked])'; [email-masked]'
Subject: RE: [Sipping] Working Group Last Call -- draft-ietf-sipping-nai-r eqs

> trust between A and C could be established. 

Well, this is not exactly what is intended. Spec(T) describes behaviour at B which enables devices which trust B to trust in the authenticity of the Network Asserted Identity information they receive from B.

More exactly, Spec(T) says that there are only two ways that Network Asserted Identity information can be obtained by B:

(i) by following some known authentication process, say Aut(T), or 
(ii) by receiving the information from another node which is known to follow Spec(T) 

So, A can know that the information it receives from B was originally generated using the process Aut(T), but it does not know (or care) which particular node used Aut(T) to do it - it might have been C.

So, it is an assumption that the reliability of the process Aut(T) is independent of the node that it is executed on - this too needs to be a requirement of Spec(T).

The whole definition is 'for the purposes of Network Asserted Identity' - so we define 'trust' only in terms of the implications for NAI. It would have been more accurate to talk about 'NAI-trust' and 'NAI-Trust-Domains'. This was in response to comments that generalised 'transitive trust' was dangerous ground.

> other words, that would be represented by an additional 

The diagram is just an example, and, although we didn't consider this case, if (i) it were possible for C to sign a message and send it through B to A and (ii) A had configuration knowledge that C was a member of the trust domain, then I suppose this is indeed equivalent to a secure connection between A and C in the terms of the definition. I can't see that this causes a problem.