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

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Dec 2007 15:51:01 +0000

Sumanth,

Draft 14 is getting there. However, I do still have some detailed
comments, particularly relating to security and to normative language.
The comments below do not include comments in the Security
Considerations section (9), which I need to read yet again and try to
formulate some meaningful comments. Here are my comments on earlier
parts.

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?

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.

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

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

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?

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?

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.

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?

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.

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

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.

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

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

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.

15. Yet another comment on the above. How does the PDS know that the
device is being 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.

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.

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.

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

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.

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.

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. 

John

_______________________________________________
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