Subject: [Sipping] Re: More comments on config-framework-14

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 4 Dec 2007 11:13:13 -0700

John,

Please find responses inline.

1. "Once authentication is successful, the PDS MAY

      admit or reject the enrollment request, based on applicable

      authorization policies."

This gives the PDS permission to admit or reject, but what is the

alternative if you don't do one of these? Surely the PDS MUST do either

one or the other?

[S] The intent was to say that it either admits or rejects it. I don't
think there is an alternative that is implied (perhaps a different
choice of words would make it clearer?).

2. "When it receives the SIP NOTIFY message, indicating successful

      profile enrollment, the device MUST make the new profile effective

      within the specified timeframe, as described in Section 6.2."

In the content indirect case, the device is dependent on how long it

takes to retrieve the content, and therefore may be unable to comply

with this MUST. I don't think we can use MUST for something that might

not be under the control of an entity to which it applies.

[S] In the case of content indirection, I agree that there are other
factors. However, the client needs to try and obtain the profile and try
to make it effective within the indicated time. Perhaps we should change
this to a SHOULD, with the exception being unavailability to obtain the
profile on time when content indirection is used? For if it does obtain
profile data in a timely manner (even with content indirection) it would
need to make it effective within the indicated timeframe.

3. "For profile data that contains

   sensitive information, authentication and message integrity are

   required to ensure that the profile contents were received by a valid

   entity, from a valid source, and without any modifications during

   transit.  For profiles that contain sensitive data, privacy is also

   required."

Surely even non-sensitive data requires authentication and message

integrity. Of course, it depends what is meant exactly by sensitive

data. Should it say:

"Authentication and message integrity are

   required to ensure that the profile contents were received by a valid

   entity, from a valid source, and without any modifications during

   transit.  For profiles that contain sensitive data, privacy is also

   required."

[S] I can go either way. I wanted to make it clear that this is vital in
the presence of sensitive data.

4. "For the

   device to authenticate the PDS, the device MUST mutually authenticate

   with the PDS during digest authentication (device challenges the

   client that responds with the Authorization header)."

This is an ambiguous use of the word "client". It would be clearer to

say "PDS". Also in "client that responds" the word "that" is defining -

it should instead be "which" and comma separated. So I would suggest:

"...device challenges the PDS, which responds..."

[S] Agree

5. "Transmission of

   sensitive profile data also requires message integrity.  This can be

   provided by configuring the device with a SIPS URI resulting in TLS

   establishment ([RFC4346])."

Presumably this is the URI of the PDS. What if the URI is discovered

rather than configured? Can't it be a SIPS URI in that case too?

[S] Yes.

6. "When the PDS challenges a profile enrollment request, and it fails,

   the PDS MAY refuse enrollment or provide profile data without the

   user-specific information (e.g., to bootstrap a device that may have

   misplaced credentials)."

Can't the PDS also accept enrollment and use content indirection?

[S] Well, if it fails authentication, it knows that it is not the right
device (or it has misplaced credentials). In such a case it can provide
profile data without user-specific information, which can include
content indirection as well.

7. "If the device challenges, but fails to

   authenticate the PDS, it MUST reject the initial notification and

   retry the profile enrollment process."

How many times should it retry? Surely not ad infinitum.

[S] This is indicated by the backoff and retry mechanism. 

8. "If the device is configured

   with a SIPS URI and TLS establishment fails because the next-hop SIP

   entity does not support TLS,"

What if the URI is discovered rather than configured?

[S] We should probably say "configured or discovered" 

9. "When the device establishes TLS with the

   next-hop entity, the device MUST use the procedures specified in

   [RFC2818], Section 3.1, for authentication, unless it does not have

   any configured information to verify the same (e.g., prior to

   bootstrapping)."

Presumably the lack of configured information for verification refers to

the lack of a CA certificate. Perhaps this should be stated.

[S] We can make that clear. 

10. "When the device establishes TLS with the

   next-hop entity, the device MUST use the procedures specified in

   [RFC2818], Section 3.1, for authentication, unless it does not have

   any configured information to verify the same (e.g., prior to

   bootstrapping).  The 'Server Identity' in this case is always the

   domain of the next-hop SIP entity."

In which case? The words "in the case" seem to refer to "unless it does

not have any configured information to verify the same". This doesn't

seem to make sense. Perhaps it should say:

"...The 'Server Identity' for authentication is always the

   domain of the next-hop SIP entity."

[S] Yes, if that makes it clear.

11. "If the device attempts

   validation, and it fails, it MUST reject the intial notification and

   retry profile enrollment."

How many times should it retry? Surely not ad infinitum.

[S] This is indicated by the backoff and retry mechanism. 

12. "In the absence of TLS and a mechanism for

   mutual authentication, the PDS MUST NOT present any sensitive profile

   data in the initial notification, except when the device is being

   boostrapped."

Perhaps we should be a bit more explicit about how to determine if TLS

is used:

"In the absence of a SIPS contact URI for the device and a mechanism for

   mutual authentication, the PDS MUST NOT present any sensitive profile

   data in the initial notification, except when the device is being

   bootstrapped."

[S] That's fine by me.

13. In the same paragraph it talks about the absence of a mechanism for

mutual authentication. It is not important to the PDS whether the device

has authenticated the PDS - what is important is whether the PDS has

authenticated the device. But earlier it states that the PDS MUST

authenticate the device, except during the bootstrapping scenario when

the device does not have existing credentials. So the only exception is

when the device is being bootstrapped. Therefore the sentence can be

shortened further as follows:

"In the absence of a SIPS contact URI for the device, the PDS MUST NOT

present any sensitive profile

   data in the initial notification, except when the device is being

   bootstrapped."

[S] That's fine by me.

14. "When a device is being provided with bootstrapping profile data

   containing sensitive information, the PDS SHOULD use the SIP Identity

   header as specified in [RFC4474] within the notification."

According to RFC 4474, Identity is inserted by an Authentication

Service, which is functionally separate from the PDS. Typically this

would be accessed from the domain proxy. I don't think we should assume

the PDS itself can insert an Identity header field. One possible

solution might be to mandate that an AS be available to the PDS for

achieving this. Another possibility might be to mandate that a proxy

that supports this RFC must be able to make use of an AS. Note that

there are already special requirements on proxies for routing SUBSCRIBE

requests to an appropriate AS, so imposing additional requirements on

proxies is not out of the question.

[S] What prevents a PDS from providing this functionality (as opposed to
a SIP Proxy)? It can perform the role of an Authentication Service as
well, no?

15. Yet another comment on the above. How does the PDS know that the

device is being bootstrapped?

[S] This is left to the service provider. For example, an operator may
decide to bootstrap every "unknown" device with minimal information to
enable trial or subscription services. Alternatively, a potential
subscriber could call a provider, indicate the device s/he wants to use,
and ask for it to be bootstrapped.

16. "Further, the profile data

   may contain the domain certificate used for creating the SIP Identity

   header, for devices that are not pre-configured with any information,

   and can be used to guarantee header and body integrity."

It is really hard to figure out what this means. If the Identity header

field is included, then of course the Identity-Info header field will

also be included, and this allows the device to verify the signature,

subject to the device being able to verify the certificate. This implies

that the device is in possession of a CA certificate that can verify the

domain certificate. So perhaps what the sentence means is the CA

certificate (or possibly the domain certificate if it is self-signed) is

contained within the profile data. But then it is too late to use it to

guarantee header and body integrity for the present NOTIFY request. That

has to be trusted. It can be used for subsequent NOTIFY requests.

[S] You are right in what it means. However, I am not sure if it is too
late to guarantee header and body integrity. One can still extract the
CA cert (or domain cert in the self-signed scenario) and then re-check
the NOTIFY (assuming it is cached), no?

17. "A device that is being provided with profile

   data that contains sensitive data MUST be authenticated using digest

   authentication as specified in [RFC2617], with the exception of a

   device that is being bootstrapped for the first time via the device

   profile."

How does the PCC know that the device is being bootstrapped? Why is the

exception limited to the device profile? In some situations not all

profiles will be used, so if the device profile is skipped, what

provision will there be for bootstrapping.

[S] The framework allows for bootstrapping using the device profile to
minimize profiles that mandatorily need to contain sensitive profile
data. So, a device that needs to be bootstrapped would need to support
the device profile. 

18. I really think bootstrapping has such a significant impact on

security considerations that it should be separated out within 5.2.1 and

5.2.2 into separate sub-sections.

[S] I am not sure if we can call it out separately since bootstrapping
forms an exception to some security considerations. However, we do have
a section on how Identities and Credentials are bootstrapped into a
device (5.3.1). 

19. "However, for sensitive profile data that needs privacy and

   is not being transmitted over a channel such as TLS, the PDS MUST use

   content indirection."

I think the only thing we can base this decision on is whether the PDS

has a SIPS contact URI for the device. So change to:

"However, for sensitive profile data that needs privacy, if the contact

URI to which the NOTIFY request is to be sent is not SIPS, the PDS MUST

use content indirection."

[S] Sounds good to me.

20. "When requesting a profile the device can provide an identity such

as

   a user AoR."

What are the alternatives if it is not an AoR? As far as I can see, it

needs the AoR for the user profile but doesn't need anything for the

other profiles.

[S] It can also present a configured (e.g., via a previously obtained
profile) user AoR for the local-network and device profiles.

21. "*  Profile data that allows the end-user to communicate by non-SIP

         means with the device provider or SIP service provider.  The

         provider can then use any applicable method (e.g., web portal)

         to provide the user AoR."

I am not sure I understand this statement. The previous sentence says

that even without any pre-configured information, it can access the

local network and device profiles. So why is profile data needed to

allow it to access the device provider? Also, why would the device

provider provide a means of communicating with the SIP service provider

by non-SIP means? Why not simply provide the AoR? If it doesn't know the

AoR, it is likely it doesn't know the SIP service provider either.

[S] Keep in mind that this provides for different ways by which
Identities and Credentials are provided to a device. The previous
statement says that the device can still request local-network and
device profiles. The quoted statement allows for the provided profile
data to contain other means for the end-user to communicate with the
provider. As an example, I could buy a SIP device from a retail
electronics store; connect it to a service provider who provides a
device profile that redirects me to a webpage. I can then use the
webpage to successfully obtain a subscription and then proceed to be
bootstrapped. (The provider may not be willing to provide a user AoR
without a subscription.) 

22. "This framework

   specifies only digest authentication and the device is not expected

   to contain any other credentials."

But the penultimate bullet above talks about the device having an "X.509

certificate that can be authenticated by the PCC". There seems to be

some inconsistency here. 

[S] I think this should be clarified. The X.509 certificate was an
example for content indirection. However, we do not specify the use of
certificates for profile enrollment.

- S

 

 

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Wed, 05 Dec 2007 01:13:57 +0000

Sumanth,

Thanks. See below.

John 

> -----Original Message-----
> From: Sumanth Channabasappa [mailto:[email-masked]] 
> Sent: 04 December 2007 18:13
> To: [email-masked]; Elwell, John
> Subject: [Sipping] Re: More comments on config-framework-14
> 
> John,
> 
>  
> 
> [S] The intent was to say that it either admits or rejects 
> it. I don't think there is an alternative that is implied 
> (perhaps a different choice of words would make it clearer?).
[JRE] "... the PDS MUST either admit or reject..." 

> [S] In the case of content indirection, I agree that there 
> are other factors. However, the client needs to try and 
> obtain the profile and try to make it effective within the 
> indicated time. Perhaps we should change this to a SHOULD, 
> with the exception being unavailability to obtain the profile 
> on time when content indirection is used? For if it does 
> obtain profile data in a timely manner (even with content 
> indirection) it would need to make it effective within the 
> indicated timeframe.
[JRE] Agreed.

> [S] I can go either way. I wanted to make it clear that this 
> is vital in the presence of sensitive data.
[JRE] I would prefer my wording, because I think authentication and
message integrity apply even to non-sensitive data.

<Deleted/>

> rather than configured? Can't it be a SIPS URI in that case too?
[JRE] So this should be clarified.

> [S] Well, if it fails authentication, it knows that it is not 
> the right device (or it has misplaced credentials). In such a 
> case it can provide profile data without user-specific 
> information, which can include content indirection as well.
[JRE] I guess I was thinking of the bootstrapping case, where the device
doesn't have the necessary credentials. In this case it would not fail
authentication - it would simply not be able to provide authentication.
Is this covered somewhere else?

> [S] This is indicated by the backoff and retry mechanism. 
[JRE] OK

> [S] We should probably say "configured or discovered" 
[JRE] OK

<deleted/> 

> [S] What prevents a PDS from providing this functionality (as 
> opposed to a SIP Proxy)? It can perform the role of an 
> Authentication Service as well, no?
[JRE] Yes it can, but do we really want to mandate this?

> [S] This is left to the service provider. For example, an 
> operator may decide to bootstrap every "unknown" device with 
> minimal information to enable trial or subscription services. 
> Alternatively, a potential subscriber could call a provider, 
> indicate the device s/he wants to use, and ask for it to be 
> bootstrapped.
[JRE] Does the WG feel that some discussion of this would be good?

> [S] You are right in what it means. However, I am not sure if 
> it is too late to guarantee header and body integrity. One 
> can still extract the CA cert (or domain cert in the 
> self-signed scenario) and then re-check the NOTIFY (assuming 
> it is cached), no?
[JRE] Well, I suppose it need not be considered too late. However, there
are zero security properties in doing so. A MitM can modify the message
and put his own certificate in there and resign. Then integrity will
appear to be correct, even though it has been compromised.

> [S] The framework allows for bootstrapping using the device 
> profile to minimize profiles that mandatorily need to contain 
> sensitive profile data. So, a device that needs to be 
> bootstrapped would need to support the device profile.
[JRE] Sounds reasonable - is this stated somewhere?

> [S] I am not sure if we can call it out separately since 
> bootstrapping forms an exception to some security 
> considerations. However, we do have a section on how 
> Identities and Credentials are bootstrapped into a device (5.3.1). 
{JRE] I guess the problem is partly because of the order of things. In
5.2.1 it says "except during the bootstrapping scenario", which hasn't
yet been described. As a minimum we need a forward reference to 5.3.1.
But I am not particularly happy about making several references to
bootstrapping in 5.2.x before the concept is described in 5.3.1.

<deleted/>
> [S] It can also present a configured (e.g., via a previously 
> obtained profile) user AoR for the local-network and device profiles.
[JRE] But it is still a user AoR, so why do we have the words "such as a
user AoR"?

> [S] Keep in mind that this provides for different ways by 
> which Identities and Credentials are provided to a device. 
> The previous statement says that the device can still request 
> local-network and device profiles. The quoted statement 
> allows for the provided profile data to contain other means 
> for the end-user to communicate with the provider. As an 
> example, I could buy a SIP device from a retail electronics 
> store; connect it to a service provider who provides a device 
> profile that redirects me to a webpage. I can then use the 
> webpage to successfully obtain a subscription and then 
> proceed to be bootstrapped. (The provider may not be willing 
> to provide a user AoR without a subscription.) 
[JRE] OK - needs some words to explain this.

<deleted/>

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 5 Dec 2007 13:36:59 -0700

John,

Thanks again. Some more responses inline (I have deleted comments and
resolutions that were agreed upon, or resolved.)

[JRE] I guess I was thinking of the bootstrapping case, where the device
doesn't have the necessary credentials. In this case it would not fail
authentication - it would simply not be able to provide authentication.
Is this covered somewhere else?
[S] The bootstrapping case is provided as an example in the statement
you originally quoted. We also have a section on how we provide such
devices with Identities and Credentials. Perhaps we can make it explicit
and add a forward reference to the section on bootstrapping?

[JRE] Yes it can, but do we really want to mandate this?
[S] I don't have a strong opinion on whether we should mandate that the
PDS needs to insert the identity. However, I would not like to preclude
the PDS from doing it. We could require the presence of the Identity,
but leave the insertion to a PDS or a SIP Proxy. 

[JRE] Does the WG feel that some discussion of this would be good?
[S] There is already some discussion in Section 9.2. There is also an
indicator in Section 5.3.4 which provides recommendations for profile
data definitions. Perhaps Section 5.3.4 can provide more clarification
on why just the device profile?

[JRE] Well, I suppose it need not be considered too late. However, there
are zero security properties in doing so. A MitM can modify the message
and put his own certificate in there and resign. Then integrity will
appear to be correct, even though it has been compromised.
[S] In that case (MiM), it cannot be used for subsequent verification
either, right? The idea, however, is that it provides a way to identify
the 'domain name' from which the information was received (and the
certificates used to prove that identity), and allows for the device to
potentially accept or reject bootstrapping information. This can be done
using pre-configured data or by presenting this information to the
end-user (as indicated in subsequent statements in the I-D).

[JRE] Sounds reasonable - is this stated somewhere?
[S] Sections 5.3.4 and 9.2. As stated earlier, I can make this more
explicit and add more details.

{JRE] I guess the problem is partly because of the order of things. In
5.2.1 it says "except during the bootstrapping scenario", which hasn't
yet been described. As a minimum we need a forward reference to 5.3.1.
But I am not particularly happy about making several references to
bootstrapping in 5.2.x before the concept is described in 5.3.1.
[S] We could add some introduction to bootstrapping and forward
reference to the section describing it before its usage in the section.

[JRE] But it is still a user AoR, so why do we have the words "such as a
user AoR"?
[S] OK - I did not see that. It is a leftover from when we also allowed
for a 'device AoR' (a special user AoR representing the device). Since
we removed 'device AoR', I will remove the 'such as'.

- S

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 05 Dec 2007 21:24:22 +0000

Sumanth,

It looks like we have a way forward on all the points except one - see
below.

> end-user (as indicated in subsequent statements in the I-D).
[JRE]Perhaps my previous response was misleading, so I will try again.
Obviously during bootstrapping some compromises have to be made, and
these have to be compensated for by some out-of-band means (e.g.,
allowing the user a small time window in which to make contact with the
PDS and obtain information needed). Such an initial connection, whilst
insecure from a SIP perspective, is considered secure because of the
out-of-band measures that are taken. There seems little point in using
the downloaded CA certificate as a means of validating the certificate
used for SIP Identity on this particular request - it should just be
stored for use on future requests where it does add value, since the
out-of-band measures taken during the initial contact do not apply.

Also I believe that trying to use a certificate received in the body of
a request to verify that request is likely to break many SIP
implementation architectures, which might want to complete verification
of the request before passing to higher layers to process bodies.

John

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 5 Dec 2007 15:23:04 -0700

John,

Inline...

Also I believe that trying to use a certificate received in the body of
a request to verify that request is likely to break many SIP
implementation architectures, which might want to complete verification
of the request before passing to higher layers to process bodies.
[S] Appreciate the clarification - I understand your concern better now.
The original intent was to try and add additional security measures to
the bootstrapping process. But if we feel that it may not add additional
value, and can actually affect existing stack implementations, I would
be fine with removing such requirements and recommendations. We may then
want to point out that it is the responsibility of out-of-band
mechanisms to consider the risks, and present suitable mitigation
strategies.

Thanks
- S