RFC4474 日本語訳
4474 Enhancements for Authenticated Identity Management in the SessionInitiation Protocol (SIP). J. Peterson, C. Jennings. August 2006. (Format: TXT=104952 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson
Request for Comments: 4474 NeuStar
Category: Standards Track C. Jennings
Cisco Systems
August 2006
Network Working Group J. Peterson Request for Comments: 4474 NeuStar Category: Standards Track C. Jennings Cisco Systems August 2006
Enhancements for Authenticated Identity Management in the
Session Initiation Protocol (SIP)
Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
Abstract
The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.
The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.
Peterson & Jennings Standards Track [Page 1] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 1] RFC 4474 SIP Identity August 2006
Table of Contents
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background ......................................................3
4. Overview of Operations ..........................................6
5. Authentication Service Behavior .................................7
5.1. Identity within a Dialog and Retargeting ..................10
6. Verifier Behavior ..............................................11
7. Considerations for User Agent ..................................12
8. Considerations for Proxy Servers ...............................13
9. Header Syntax ..................................................13
10. Compliance Tests and Examples .................................16
10.1. Identity-Info with a Singlepart MIME body ................17
10.2. Identity for a Request with No MIME Body or Contact ......20
11. Identity and the TEL URI Scheme ...............................22
12. Privacy Considerations ........................................23
13. Security Considerations .......................................24
13.1. Handling of digest-string Elements .......................24
13.2. Display-Names and Identity ...............................27
13.3. Securing the Connection to the Authentication Service ....28
13.4. Domain Names and Subordination ...........................29
13.5. Authorization and Transitional Strategies ................30
14. IANA Considerations ...........................................31
14.1. Header Field Names .......................................31
14.2. 428 'Use Identity Header' Response Code ..................32
14.3. 436 'Bad Identity-Info' Response Code ....................32
14.4. 437 'Unsupported Certificate' Response Code ..............32
14.5. 438 'Invalid Identity Header' Response Code ..............33
14.6. Identity-Info Parameters .................................33
14.7. Identity-Info Algorithm Parameter Values .................33
Appendix A. Acknowledgements ......................................34
Appendix B. Bit-Exact Archive of Examples of Messages .............34
B.1. Encoded Reference Files ...................................35
Appendix C. Original Requirements .................................38
References ........................................................39
Normative References ...........................................39
Informative References .........................................39
1. Introduction ....................................................3 2. Terminology .....................................................3 3. Background ......................................................3 4. Overview of Operations ..........................................6 5. Authentication Service Behavior .................................7 5.1. Identity within a Dialog and Retargeting ..................10 6. Verifier Behavior ..............................................11 7. Considerations for User Agent ..................................12 8. Considerations for Proxy Servers ...............................13 9. Header Syntax ..................................................13 10. Compliance Tests and Examples .................................16 10.1. Identity-Info with a Singlepart MIME body ................17 10.2. Identity for a Request with No MIME Body or Contact ......20 11. Identity and the TEL URI Scheme ...............................22 12. Privacy Considerations ........................................23 13. Security Considerations .......................................24 13.1. Handling of digest-string Elements .......................24 13.2. Display-Names and Identity ...............................27 13.3. Securing the Connection to the Authentication Service ....28 13.4. Domain Names and Subordination ...........................29 13.5. Authorization and Transitional Strategies ................30 14. IANA Considerations ...........................................31 14.1. Header Field Names .......................................31 14.2. 428 'Use Identity Header' Response Code ..................32 14.3. 436 'Bad Identity-Info' Response Code ....................32 14.4. 437 'Unsupported Certificate' Response Code ..............32 14.5. 438 'Invalid Identity Header' Response Code ..............33 14.6. Identity-Info Parameters .................................33 14.7. Identity-Info Algorithm Parameter Values .................33 Appendix A. Acknowledgements ......................................34 Appendix B. Bit-Exact Archive of Examples of Messages .............34 B.1. Encoded Reference Files ...................................35 Appendix C. Original Requirements .................................38 References ........................................................39 Normative References ...........................................39 Informative References .........................................39
Peterson & Jennings Standards Track [Page 2] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 2] RFC 4474 SIP Identity August 2006
1. Introduction
1. Introduction
This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP, RFC 3261 [1]). An identity, for the purposes of this document, is defined as a SIP URI, commonly a canonical address-of-record (AoR) employed to reach a user (such as 'sip:alice@atlanta.example.com').
This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP, RFC 3261 [1]). An identity, for the purposes of this document, is defined as a SIP URI, commonly a canonical address-of-record (AoR) employed to reach a user (such as 'sip:alice@atlanta.example.com').
RFC 3261 stipulates several places within a SIP request where a user can express an identity for themselves, notably the user-populated From header field. However, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately, in the absence of some sort of cryptographic authentication mechanism.
RFC 3261 stipulates several places within a SIP request where a user can express an identity for themselves, notably the user-populated From header field. However, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately, in the absence of some sort of cryptographic authentication mechanism.
RFC 3261 specifies a number of security mechanisms that can be employed by SIP user agents (UAs), including Digest, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes as well). However, few SIP user agents today support the end-user certificates necessary to authenticate themselves (via S/MIME, for example), and furthermore Digest authentication is limited by the fact that the originator and destination must share a prearranged secret. It is desirable for SIP user agents to be able to send requests to destinations with which they have no previous association -- just as in the telephone network today, one can receive a call from someone with whom one has no previous association, and still have a reasonable assurance that the person's displayed Caller-ID is accurate. A cryptographic approach, like the one described in this document, can probably provide a much stronger and less-spoofable assurance of identity than the telephone network provides today.
RFC 3261 specifies a number of security mechanisms that can be employed by SIP user agents (UAs), including Digest, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes as well). However, few SIP user agents today support the end-user certificates necessary to authenticate themselves (via S/MIME, for example), and furthermore Digest authentication is limited by the fact that the originator and destination must share a prearranged secret. It is desirable for SIP user agents to be able to send requests to destinations with which they have no previous association -- just as in the telephone network today, one can receive a call from someone with whom one has no previous association, and still have a reasonable assurance that the person's displayed Caller-ID is accurate. A cryptographic approach, like the one described in this document, can probably provide a much stronger and less-spoofable assurance of identity than the telephone network provides today.
2. Terminology
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
3. Background
3. Background
The usage of many SIP applications and services is governed by authorization policies. These policies may be automated, or they may be applied manually by humans. An example of the latter would be an Internet telephone application that displays the Caller-ID of a caller, which a human may review before answering a call. An example of the former would be a presence service that compares the identity
The usage of many SIP applications and services is governed by authorization policies. These policies may be automated, or they may be applied manually by humans. An example of the latter would be an Internet telephone application that displays the Caller-ID of a caller, which a human may review before answering a call. An example of the former would be a presence service that compares the identity
Peterson & Jennings Standards Track [Page 3] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 3] RFC 4474 SIP Identity August 2006
of potential subscribers to a whitelist before determining whether it should accept or reject the subscription. In both of these cases, attackers might attempt to circumvent these authorization policies through impersonation. Since the primary identifier of the sender of a SIP request, the From header field, can be populated arbitrarily by the controller of a user agent, impersonation is very simple today. The mechanism described in this document aspires to provide a strong identity system for SIP in which authorization policies cannot be circumvented by impersonation.
of potential subscribers to a whitelist before determining whether it should accept or reject the subscription. In both of these cases, attackers might attempt to circumvent these authorization policies through impersonation. Since the primary identifier of the sender of a SIP request, the From header field, can be populated arbitrarily by the controller of a user agent, impersonation is very simple today. The mechanism described in this document aspires to provide a strong identity system for SIP in which authorization policies cannot be circumvented by impersonation.
All RFC 3261-compliant user agents support Digest authentication, which utilizes a shared secret, as a means for authenticating themselves to a SIP registrar. Registration allows a user agent to express that it is an appropriate entity to which requests should be sent for a particular SIP AoR URI (e.g., 'sip:alice@atlanta.example.com').
All RFC 3261-compliant user agents support Digest authentication, which utilizes a shared secret, as a means for authenticating themselves to a SIP registrar. Registration allows a user agent to express that it is an appropriate entity to which requests should be sent for a particular SIP AoR URI (e.g., 'sip:alice@atlanta.example.com').
By the definition of identity used in this document, registration is a proof of the identity of the user to a registrar. However, the credentials with which a user agent proves its identity to a registrar cannot be validated by just any user agent or proxy server -- these credentials are only shared between the user agent and their domain administrator. So this shared secret does not immediately help a user to authenticate to a wide range of recipients. Recipients require a means of determining whether or not the 'return address' identity of a non-REGISTER request (i.e., the From header field value) has legitimately been asserted.
By the definition of identity used in this document, registration is a proof of the identity of the user to a registrar. However, the credentials with which a user agent proves its identity to a registrar cannot be validated by just any user agent or proxy server -- these credentials are only shared between the user agent and their domain administrator. So this shared secret does not immediately help a user to authenticate to a wide range of recipients. Recipients require a means of determining whether or not the 'return address' identity of a non-REGISTER request (i.e., the From header field value) has legitimately been asserted.
The AoR URI used for registration is also the URI with which a UA commonly populates the From header field of requests in order to provide a 'return address' identity to recipients. From an authorization perspective, if you can prove you are eligible to register in a domain under a particular AoR, you can prove you can legitimately receive requests for that AoR, and accordingly, when you place that AoR in the From header field of a SIP request other than a registration (like an INVITE), you are providing a 'return address' where you can legitimately be reached. In other words, if you are authorized to receive requests for that 'return address', logically, it follows that you are also authorized to assert that 'return address' in your From header field. This is of course only one manner in which a domain might determine how a particular user is authorized to populate the From header field; as an aside, for other sorts of URIs in the From (like anonymous URIs), other authorization policies would apply.
The AoR URI used for registration is also the URI with which a UA commonly populates the From header field of requests in order to provide a 'return address' identity to recipients. From an authorization perspective, if you can prove you are eligible to register in a domain under a particular AoR, you can prove you can legitimately receive requests for that AoR, and accordingly, when you place that AoR in the From header field of a SIP request other than a registration (like an INVITE), you are providing a 'return address' where you can legitimately be reached. In other words, if you are authorized to receive requests for that 'return address', logically, it follows that you are also authorized to assert that 'return address' in your From header field. This is of course only one manner in which a domain might determine how a particular user is authorized to populate the From header field; as an aside, for other sorts of URIs in the From (like anonymous URIs), other authorization policies would apply.
Ideally, then, SIP user agents should have some way of proving to recipients of SIP requests that their local domain has authenticated them and authorized the population of the From header field. This
Ideally, then, SIP user agents should have some way of proving to recipients of SIP requests that their local domain has authenticated them and authorized the population of the From header field. This
Peterson & Jennings Standards Track [Page 4] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 4] RFC 4474 SIP Identity August 2006
document proposes a mediated authentication architecture for SIP in which requests are sent to a server in the user's local domain, which authenticates such requests (using the same practices by which the domain would authenticate REGISTER requests). Once a message has been authenticated, the local domain then needs some way to communicate to other SIP entities that the sending user has been authenticated and its use of the From header field has been authorized. This document addresses how that imprimatur of authentication can be shared.
document proposes a mediated authentication architecture for SIP in which requests are sent to a server in the user's local domain, which authenticates such requests (using the same practices by which the domain would authenticate REGISTER requests). Once a message has been authenticated, the local domain then needs some way to communicate to other SIP entities that the sending user has been authenticated and its use of the From header field has been authorized. This document addresses how that imprimatur of authentication can be shared.
RFC 3261 already describes an architecture very similar to this in Section 26.3.2.2, in which a user agent authenticates itself to a local proxy server, which in turn authenticates itself to a remote proxy server via mutual TLS, creating a two-link chain of transitive authentication between the originator and the remote domain. While this works well in some architectures, there are a few respects in which this is impractical. For one, transitive trust is inherently weaker than an assertion that can be validated end-to-end. It is possible for SIP requests to cross multiple intermediaries in separate administrative domains, in which case transitive trust becomes even less compelling.
RFC 3261 already describes an architecture very similar to this in Section 26.3.2.2, in which a user agent authenticates itself to a local proxy server, which in turn authenticates itself to a remote proxy server via mutual TLS, creating a two-link chain of transitive authentication between the originator and the remote domain. While this works well in some architectures, there are a few respects in which this is impractical. For one, transitive trust is inherently weaker than an assertion that can be validated end-to-end. It is possible for SIP requests to cross multiple intermediaries in separate administrative domains, in which case transitive trust becomes even less compelling.
One solution to this problem is to use 'trusted' SIP intermediaries that assert an identity for users in the form of a privileged SIP header. A mechanism for doing so (with the P-Asserted-Identity header) is given in [12]. However, this solution allows only hop- by-hop trust between intermediaries, not end-to-end cryptographic authentication, and it assumes a managed network of nodes with strict mutual trust relationships, an assumption that is incompatible with widespread Internet deployment.
One solution to this problem is to use 'trusted' SIP intermediaries that assert an identity for users in the form of a privileged SIP header. A mechanism for doing so (with the P-Asserted-Identity header) is given in [12]. However, this solution allows only hop- by-hop trust between intermediaries, not end-to-end cryptographic authentication, and it assumes a managed network of nodes with strict mutual trust relationships, an assumption that is incompatible with widespread Internet deployment.
Accordingly, this document specifies a means of sharing a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context that is based on the concept of an 'authentication service' and a new SIP header, the Identity header. Note that the scope of this document is limited to providing this identity assurance for SIP requests; solving this problem for SIP responses is more complicated and is a subject for future work.
Accordingly, this document specifies a means of sharing a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context that is based on the concept of an 'authentication service' and a new SIP header, the Identity header. Note that the scope of this document is limited to providing this identity assurance for SIP requests; solving this problem for SIP responses is more complicated and is a subject for future work.
This specification allows either a user agent or a proxy server to provide identity services and to verify identities. To maximize end-to-end security, it is obviously preferable for end-users to acquire their own certificates and corresponding private keys; if they do, they can act as an authentication service. However, end- user certificates may be neither practical nor affordable, given the difficulties of establishing a Public Key Infrastructure (PKI) that extends to end-users, and moreover, given the potentially large number of SIP user agents (phones, PCs, laptops, PDAs, gaming
This specification allows either a user agent or a proxy server to provide identity services and to verify identities. To maximize end-to-end security, it is obviously preferable for end-users to acquire their own certificates and corresponding private keys; if they do, they can act as an authentication service. However, end- user certificates may be neither practical nor affordable, given the difficulties of establishing a Public Key Infrastructure (PKI) that extends to end-users, and moreover, given the potentially large number of SIP user agents (phones, PCs, laptops, PDAs, gaming
Peterson & Jennings Standards Track [Page 5] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 5] RFC 4474 SIP Identity August 2006
devices) that may be employed by a single user. In such environments, synchronizing keying material across multiple devices may be very complex and requires quite a good deal of additional endpoint behavior. Managing several certificates for the various devices is also quite problematic and unpopular with users. Accordingly, in the initial use of this mechanism, it is likely that intermediaries will instantiate the authentication service role.
devices) that may be employed by a single user. In such environments, synchronizing keying material across multiple devices may be very complex and requires quite a good deal of additional endpoint behavior. Managing several certificates for the various devices is also quite problematic and unpopular with users. Accordingly, in the initial use of this mechanism, it is likely that intermediaries will instantiate the authentication service role.
4. Overview of Operations
4. Overview of Operations
This section provides an informative (non-normative) high-level overview of the mechanisms described in this document.
This section provides an informative (non-normative) high-level overview of the mechanisms described in this document.
Imagine the case where Alice, who has the home proxy of example.com and the address-of-record sip:alice@example.com, wants to communicate with sip:bob@example.org.
Imagine the case where Alice, who has the home proxy of example.com and the address-of-record sip:alice@example.com, wants to communicate with sip:bob@example.org.
Alice generates an INVITE and places her identity in the From header field of the request. She then sends an INVITE over TLS to an authentication service proxy for her domain.
Alice generates an INVITE and places her identity in the From header field of the request. She then sends an INVITE over TLS to an authentication service proxy for her domain.
The authentication service authenticates Alice (possibly by sending a Digest authentication challenge) and validates that she is authorized to assert the identity that is populated in the From header field. This value may be Alice's AoR, or it may be some other value that the policy of the proxy server permits her to use. It then computes a hash over some particular headers, including the From header field and the bodies in the message. This hash is signed with the certificate for the domain (example.com, in Alice's case) and inserted in a new header field in the SIP message, the 'Identity' header.
The authentication service authenticates Alice (possibly by sending a Digest authentication challenge) and validates that she is authorized to assert the identity that is populated in the From header field. This value may be Alice's AoR, or it may be some other value that the policy of the proxy server permits her to use. It then computes a hash over some particular headers, including the From header field and the bodies in the message. This hash is signed with the certificate for the domain (example.com, in Alice's case) and inserted in a new header field in the SIP message, the 'Identity' header.
The proxy, as the holder of the private key of its domain, is asserting that the originator of this request has been authenticated and that she is authorized to claim the identity (the SIP address- of-record) that appears in the From header field. The proxy also inserts a companion header field, Identity-Info, that tells Bob how to acquire its certificate, if he doesn't already have it.
The proxy, as the holder of the private key of its domain, is asserting that the originator of this request has been authenticated and that she is authorized to claim the identity (the SIP address- of-record) that appears in the From header field. The proxy also inserts a companion header field, Identity-Info, that tells Bob how to acquire its certificate, if he doesn't already have it.
When Bob's domain receives the request, it verifies the signature provided in the Identity header, and thus can validate that the domain indicated by the host portion of the AoR in the From header field authenticated the user, and permitted the user to assert that From header field value. This same validation operation may be performed by Bob's user agent server (UAS).
When Bob's domain receives the request, it verifies the signature provided in the Identity header, and thus can validate that the domain indicated by the host portion of the AoR in the From header field authenticated the user, and permitted the user to assert that From header field value. This same validation operation may be performed by Bob's user agent server (UAS).
Peterson & Jennings Standards Track [Page 6] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 6] RFC 4474 SIP Identity August 2006
5. Authentication Service Behavior
5. Authentication Service Behavior
This document defines a new role for SIP entities called an authentication service. The authentication service role can be instantiated by a proxy server or a user agent. Any entity that instantiates the authentication service role MUST possess the private key of a domain certificate. Intermediaries that instantiate this role MUST be capable of authenticating one or more SIP users that can register in that domain. Commonly, this role will be instantiated by a proxy server, since these entities are more likely to have a static hostname, hold a corresponding certificate, and have access to SIP registrar capabilities that allow them to authenticate users in their domain. It is also possible that the authentication service role might be instantiated by an entity that acts as a redirect server, but that is left as a topic for future work.
This document defines a new role for SIP entities called an authentication service. The authentication service role can be instantiated by a proxy server or a user agent. Any entity that instantiates the authentication service role MUST possess the private key of a domain certificate. Intermediaries that instantiate this role MUST be capable of authenticating one or more SIP users that can register in that domain. Commonly, this role will be instantiated by a proxy server, since these entities are more likely to have a static hostname, hold a corresponding certificate, and have access to SIP registrar capabilities that allow them to authenticate users in their domain. It is also possible that the authentication service role might be instantiated by an entity that acts as a redirect server, but that is left as a topic for future work.
SIP entities that act as an authentication service MUST add a Date header field to SIP requests if one is not already present (see Section 9 for information on how the Date header field assists verifiers). Similarly, authentication services MUST add a Content- Length header field to SIP requests if one is not already present; this can help verifiers to double-check that they are hashing exactly as many bytes of message-body as the authentication service when they verify the message.
SIP entities that act as an authentication service MUST add a Date header field to SIP requests if one is not already present (see Section 9 for information on how the Date header field assists verifiers). Similarly, authentication services MUST add a Content- Length header field to SIP requests if one is not already present; this can help verifiers to double-check that they are hashing exactly as many bytes of message-body as the authentication service when they verify the message.
Entities instantiating the authentication service role perform the following steps, in order, to generate an Identity header for a SIP request:
Entities instantiating the authentication service role perform the following steps, in order, to generate an Identity header for a SIP request:
Step 1:
Step 1:
The authentication service MUST extract the identity of the sender from the request. The authentication service takes this value from the From header field; this AoR will be referred to here as the 'identity field'. If the identity field contains a SIP or SIP Secure (SIPS) URI, the authentication service MUST extract the hostname portion of the identity field and compare it to the domain(s) for which it is responsible (following the procedures in RFC 3261, Section 16.4, used by a proxy server to determine the domain(s) for which it is responsible). If the identity field uses the TEL URI scheme, the policy of the authentication service determines whether or not it is responsible for this identity; see Section 11 for more information. If the authentication service is not responsible for the identity in question, it SHOULD process and forward the request normally, but it MUST NOT add an Identity header; see below for more information on authentication service handling of an existing Identity header.
The authentication service MUST extract the identity of the sender from the request. The authentication service takes this value from the From header field; this AoR will be referred to here as the 'identity field'. If the identity field contains a SIP or SIP Secure (SIPS) URI, the authentication service MUST extract the hostname portion of the identity field and compare it to the domain(s) for which it is responsible (following the procedures in RFC 3261, Section 16.4, used by a proxy server to determine the domain(s) for which it is responsible). If the identity field uses the TEL URI scheme, the policy of the authentication service determines whether or not it is responsible for this identity; see Section 11 for more information. If the authentication service is not responsible for the identity in question, it SHOULD process and forward the request normally, but it MUST NOT add an Identity header; see below for more information on authentication service handling of an existing Identity header.
Peterson & Jennings Standards Track [Page 7] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 7] RFC 4474 SIP Identity August 2006
Step 2:
Step 2:
The authentication service MUST determine whether or not the sender of the request is authorized to claim the identity given in the identity field. In order to do so, the authentication service MUST authenticate the sender of the message. Some possible ways in which this authentication might be performed include:
The authentication service MUST determine whether or not the sender of the request is authorized to claim the identity given in the identity field. In order to do so, the authentication service MUST authenticate the sender of the message. Some possible ways in which this authentication might be performed include:
If the authentication service is instantiated by a SIP
intermediary (proxy server), it may challenge the request with
a 407 response code using the Digest authentication scheme (or
viewing a Proxy-Authentication header sent in the request,
which was sent in anticipation of a challenge using cached
credentials, as described in RFC 3261, Section 22.3). Note
that if that proxy server is maintaining a TLS connection with
the client over which the client had previously authenticated
itself using Digest authentication, the identity value obtained
from that previous authentication step can be reused without an
additional Digest challenge.
If the authentication service is instantiated by a SIP intermediary (proxy server), it may challenge the request with a 407 response code using the Digest authentication scheme (or viewing a Proxy-Authentication header sent in the request, which was sent in anticipation of a challenge using cached credentials, as described in RFC 3261, Section 22.3). Note that if that proxy server is maintaining a TLS connection with the client over which the client had previously authenticated itself using Digest authentication, the identity value obtained from that previous authentication step can be reused without an additional Digest challenge.
If the authentication service is instantiated by a SIP user
agent, a user agent can be said to authenticate its user on the
grounds that the user can provision the user agent with the
private key of the domain, or preferably by providing a
password that unlocks said private key.
If the authentication service is instantiated by a SIP user agent, a user agent can be said to authenticate its user on the grounds that the user can provision the user agent with the private key of the domain, or preferably by providing a password that unlocks said private key.
Authorization of the use of a particular username in the From header field is a matter of local policy for the authentication service, one that depends greatly on the manner in which authentication is performed. For example, one policy might be as follows: the username given in the 'username' parameter of the Proxy-Authorization header MUST correspond exactly to the username in the From header field of the SIP message. However, there are many cases in which this is too limiting or inappropriate; a realm might use 'username' parameters in Proxy-Authorization that do not correspond to the user-portion of SIP From headers, or a user might manage multiple accounts in the same administrative domain. In this latter case, a domain might maintain a mapping between the values in the 'username' parameter of Proxy- Authorization and a set of one or more SIP URIs that might legitimately be asserted for that 'username'. For example, the username can correspond to the 'private identity' as defined in Third Generation Partnership Project (3GPP), in which case the From header field can contain any one of the public identities associated with this private identity. In this instance, another policy might be as follows: the URI in the From header field MUST correspond exactly to one of the mapped URIs associated with the 'username' given in the Proxy-Authorization header. Various exceptions to such policies might arise for cases like anonymity; if the AoR asserted in the From
Authorization of the use of a particular username in the From header field is a matter of local policy for the authentication service, one that depends greatly on the manner in which authentication is performed. For example, one policy might be as follows: the username given in the 'username' parameter of the Proxy-Authorization header MUST correspond exactly to the username in the From header field of the SIP message. However, there are many cases in which this is too limiting or inappropriate; a realm might use 'username' parameters in Proxy-Authorization that do not correspond to the user-portion of SIP From headers, or a user might manage multiple accounts in the same administrative domain. In this latter case, a domain might maintain a mapping between the values in the 'username' parameter of Proxy- Authorization and a set of one or more SIP URIs that might legitimately be asserted for that 'username'. For example, the username can correspond to the 'private identity' as defined in Third Generation Partnership Project (3GPP), in which case the From header field can contain any one of the public identities associated with this private identity. In this instance, another policy might be as follows: the URI in the From header field MUST correspond exactly to one of the mapped URIs associated with the 'username' given in the Proxy-Authorization header. Various exceptions to such policies might arise for cases like anonymity; if the AoR asserted in the From
Peterson & Jennings Standards Track [Page 8] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 8] RFC 4474 SIP Identity August 2006
header field uses a form like 'sip:anonymous@example.com', then the 'example.com' proxy should authenticate that the user is a valid user in the domain and insert the signature over the From header field as usual.
header field uses a form like 'sip:anonymous@example.com', then the 'example.com' proxy should authenticate that the user is a valid user in the domain and insert the signature over the From header field as usual.
Note that this check is performed on the addr-spec in the From header field (e.g., the URI of the sender, like 'sip:alice@atlanta.example.com'); it does not convert the display- name portion of the From header field (e.g., 'Alice Atlanta'). Authentication services MAY check and validate the display-name as well, and compare it to a list of acceptable display-names that may be used by the sender; if the display-name does not meet policy constraints, the authentication service MUST return a 403 response code. The reason phrase should indicate the nature of the problem; for example, "Inappropriate Display Name". However, the display-name is not always present, and in many environments the requisite operational procedures for display-name validation may not exist. For more information, see Section 13.2.
Note that this check is performed on the addr-spec in the From header field (e.g., the URI of the sender, like 'sip:alice@atlanta.example.com'); it does not convert the display- name portion of the From header field (e.g., 'Alice Atlanta'). Authentication services MAY check and validate the display-name as well, and compare it to a list of acceptable display-names that may be used by the sender; if the display-name does not meet policy constraints, the authentication service MUST return a 403 response code. The reason phrase should indicate the nature of the problem; for example, "Inappropriate Display Name". However, the display-name is not always present, and in many environments the requisite operational procedures for display-name validation may not exist. For more information, see Section 13.2.
Step 3:
Step 3:
The authentication service SHOULD ensure that any preexisting Date header in the request is accurate. Local policy can dictate precisely how accurate the Date must be; a RECOMMENDED maximum discrepancy of ten minutes will ensure that the request is unlikely to upset any verifiers. If the Date header contains a time different by more than ten minutes from the current time noted by the authentication service, the authentication service SHOULD reject the request. This behavior is not mandatory because a user agent client (UAC) could only exploit the Date header in order to cause a request to fail verification; the Identity header is not intended to provide a source of non-repudiation or a perfect record of when messages are processed. Finally, the authentication service MUST verify that the Date header falls within the validity period of its certificate. For more information on the security properties associated with the Date header field value, see Section 9.
The authentication service SHOULD ensure that any preexisting Date header in the request is accurate. Local policy can dictate precisely how accurate the Date must be; a RECOMMENDED maximum discrepancy of ten minutes will ensure that the request is unlikely to upset any verifiers. If the Date header contains a time different by more than ten minutes from the current time noted by the authentication service, the authentication service SHOULD reject the request. This behavior is not mandatory because a user agent client (UAC) could only exploit the Date header in order to cause a request to fail verification; the Identity header is not intended to provide a source of non-repudiation or a perfect record of when messages are processed. Finally, the authentication service MUST verify that the Date header falls within the validity period of its certificate. For more information on the security properties associated with the Date header field value, see Section 9.
Step 4:
Step 4:
The authentication service MUST form the identity signature and add an Identity header to the request containing this signature. After the Identity header has been added to the request, the authentication service MUST also add an Identity-Info header. The Identity-Info header contains a URI from which its certificate can be acquired. Details on the generation of both of these headers are provided in Section 9.
The authentication service MUST form the identity signature and add an Identity header to the request containing this signature. After the Identity header has been added to the request, the authentication service MUST also add an Identity-Info header. The Identity-Info header contains a URI from which its certificate can be acquired. Details on the generation of both of these headers are provided in Section 9.
Peterson & Jennings Standards Track [Page 9] RFC 4474 SIP Identity August 2006
Peterson & Jennings Standards Track [Page 9] RFC 4474 SIP Identity August 2006
Finally, the authentication service MUST forward the message normally.
Finally, the authentication service MUST forward the message normally.
5.1. Identity within a Dialog and Retargeting
5.1. Identity within a Dialog and Retargeting
Retargeting is broadly defined as the alteration of the Request-URI by intermediaries. More specifically, retargeting supplants the original target URI with one that corresponds to a different user, a user that is not authorized to register under the original target URI. By this definition, retargeting does not include translation of the Request-URI to a contact address of an endpoint that has registered under the original target URI, for example.
Retargetingは仲介者によるRequest-URIの変更と広く定義されます。 より明確に、「再-狙」いは異なったユーザ(オリジナルの目標URIの下で登録するのは権限を与えられないユーザ)に文通されるものでオリジナルの目標URIに取って代わります。 この定義で、「再-狙」いは例えば、オリジナルの目標URIの下で登録された終点の連絡先にRequest-URIに関する翻訳を含めません。
When a dialog-forming request is retargeted, this can cause a few wrinkles for the Identity mechanism when it is applied to requests sent in the backwards direction within a dialog. This section provides some non-normative considerations related to this case.
それが対話の中で遅れている方向に送られた要求に適用されるとき、対話を形成する要求が「再-狙」うと、これはIdentityメカニズムのためにいくつかのしわを引き起こす場合があります。 このセクションは本件に関連するいくつかの非標準の問題を提供します。
When a request is retargeted, it may reach a SIP endpoint whose user is not identified by the URI designated in the To header field value. The value in the To header field of a dialog-forming request is used as the From header field of requests sent in the backwards direction during the dialog, and is accordingly the header that would be signed by an authentication service for requests sent in the backwards direction. In retargeting cases, if the URI in the From header does not identify the sender of the request in the backwards direction, then clearly it would be inappropriate to provide an Identity signature over that From header. As specified above, if the authentication service is not responsible for the domain in the From header field of the request, it MUST NOT add an Identity header to the request, and it should process/forward the request normally.
要求が「再-狙」うとき、それはユーザがToヘッダーフィールド価値で指定されたURIによって特定されないSIP終点に達するかもしれません。 対話を形成する要求のToヘッダーフィールドにおける値は、要求のFromヘッダーフィールドが対話の間、遅れている方向を送ったので使用されていて、それに従って、要求のための認証サービスで署名されるヘッダーが遅れている方向を送ったということです。 ケースを「再-狙」うのにおいて、FromヘッダーのURIが遅れている方向による要求の送付者を特定しないなら、明確に、そのFromヘッダーの上にIdentity署名を供給するのは不適当でしょう。 通常、それは、要求を上で指定されるように、認証サービスが要求のFromヘッダーフィールドにおけるドメインに原因とならないなら、Identityヘッダーを要求に追加してはいけなくて、処理するはずであるか、または転送するはずです。
Any means of anticipating retargeting, and so on, is outside the scope of this document, and likely to have equal applicability to response identity as it does to requests in the backwards direction within a dialog. Consequently, no special guidance is given for implementers here regarding the 'connected party' problem; authentication service behavior is unchanged if retargeting has occurred for a dialog-forming request. Ultimately, the authentication service provides an Identity header for requests in the backwards dialog when the user is authorized to assert the identity given in the From header field, and if they are not, an Identity header is not provided.
「再-狙」うと予期するどんな手段も、などこのドキュメントの範囲の外にあって、対話の中で遅れている方向による要求にするように応答のアイデンティティに等しい適用性を持っていそうです。 その結果、implementersのために'接続パーティー'問題に関してどんな特別な指導もここに与えません。 「再-狙」いが対話を形成する要求のために起こったなら、認証使用挙動は変わりがありません。 ユーザがFromヘッダーフィールドで与えられたアイデンティティについて断言するのに権限を与えられて、Identityヘッダーがそれらがそうでないなら、結局前提とされないとき、認証サービスは遅れている対話でIdentityヘッダーを要求に提供します。
For further information on the problems of response identity and the potential solution spaces, see [15].
応答のアイデンティティと潜在的ソリューション空間の問題の詳細に関しては、[15]を見てください。
Peterson & Jennings Standards Track [Page 10] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[10ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
6. Verifier Behavior
6. 検証の振舞い
This document introduces a new logical role for SIP entities called a server. When a verifier receives a SIP message containing an Identity header, it may inspect the signature to verify the identity of the sender of the message. Typically, the results of a verification are provided as input to an authorization process that is outside the scope of this document. If an Identity header is not present in a request, and one is required by local policy (for example, based on a per-sending-domain policy, or a per-sending-user policy), then a 428 'Use Identity Header' response MUST be sent.
このドキュメントはサーバと呼ばれるSIP実体のために新しい論理的な役割を導入します。検証がIdentityヘッダーを含むSIPメッセージを受け取るとき、それは、メッセージ送信者のアイデンティティについて確かめるために署名を点検するかもしれません。 通常、このドキュメントの範囲の外にある承認プロセスに入力されるように検証の結果を提供します。 Identityヘッダーが要求に出席していなくて、ローカルの方針(例えばドメインを送るのあたり1つの方針、またはユーザを送るのあたり1つの方針に基づいて)が1を必要とするなら、'Identity Headerを使用してください'という428応答を送らなければなりません。
In order to verify the identity of the sender of a message, an entity acting as a verifier MUST perform the following steps, in the order here specified.
メッセージの送付者のアイデンティティについて確かめるために、検証として機能する実体はここで指定されていた状態でオーダーにおける以下のステップを実行しなければなりません。
Step 1:
ステップ1:
The verifier MUST acquire the certificate for the signing domain. Implementations supporting this specification SHOULD have some means of retaining domain certificates (in accordance with normal practices for certificate lifetimes and revocation) in order to prevent themselves from needlessly downloading the same certificate every time a request from the same domain is received. Certificates cached in this manner should be indexed by the URI given in the Identity- Info header field value.
検証は署名ドメインのための証明書を入手しなければなりません。 この仕様がSHOULDであるとサポートする実装が同じドメインからの要求が受信されているときはいつも、自分たちが不必要に同じ証明書をダウンロードするのを防ぐために、ドメイン証明書(標準に従って、証明書のために生涯、取消しを練習する)を保有するいくつかの手段を持っています。 この様にキャッシュされた証明書はIdentityインフォメーションヘッダーフィールド価値で与えられたURIによって索引をつけられるべきです。
Provided that the domain certificate used to sign this message is not previously known to the verifier, SIP entities SHOULD discover this certificate by dereferencing the Identity-Info header, unless they have some more efficient implementation-specific way of acquiring certificates for that domain. If the URI scheme in the Identity-Info header cannot be dereferenced, then a 436 'Bad Identity-Info' response MUST be returned. The verifier processes this certificate in the usual ways, including checking that it has not expired, that the chain is valid back to a trusted certification authority (CA), and that it does not appear on revocation lists. Once the certificate is acquired, it MUST be validated following the procedures in RFC 3280 [9]. If the certificate cannot be validated (it is self-signed and untrusted, or signed by an untrusted or unknown certificate authority, expired, or revoked), the verifier MUST send a 437 'Unsupported Certificate' response.
このメッセージに署名するのに使用されるドメイン証明書が以前に検証に知られていなければ、SIP実体SHOULDはIdentity-インフォメーションヘッダーに「反-参照をつけ」ることによって、この証明書を発見します、それらにそのドメインのための証明書を入手する何らかの効率的な実装特有の方法がまだないなら。 Identity-インフォメーションヘッダーのURI体系に「反-参照をつけ」ることができないなら、436'悪いIdentity-インフォメーション'応答を返さなければなりません。 検証は普通の方法でこの証明書を処理します、期限が切れていなくて、またチェーンが信じられた証明権威(カリフォルニア)に有効であって戻るのであり、それが取消しリストに現れないのをチェックするのを含んでいて。 証明書がいったん後天的になると、RFC3280[9]で手順に従って、それを有効にしなければなりません。 証明書を有効にすることができないなら(それは、自己によって署名されて信頼されていなく、信頼されていないか未知の認証局によって署名されます、吐き出されるか、または取り消されて)、検証は437'サポートされないCertificate'応答を送らなければなりません。
Step 2:
ステップ2:
The verifier MUST follow the process described in Section 13.4 to determine if the signer is authoritative for the URI in the From header field.
検証はFromヘッダーフィールドにおけるURIに、署名者が正式であるかどうか決定するためにセクション13.4で説明されたプロセスに続かなければなりません。
Peterson & Jennings Standards Track [Page 11] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[11ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
Step 3:
ステップ3:
The verifier MUST verify the signature in the Identity header field, following the procedures for generating the hashed digest-string described in Section 9. If a verifier determines that the signature on the message does not correspond to the reconstructed digest- string, then a 438 'Invalid Identity Header' response MUST be returned.
検証はIdentityヘッダーフィールドにおける署名について確かめなければなりません、セクション9で説明された論じ尽くされたダイジェストストリングを生成するために手順に従って。 検証が、メッセージにおける署名が再建されたダイジェストストリングと食い違っていることを決定するなら、438'無効のIdentity Header'応答を返さなければなりません。
Step 4:
ステップ4:
The verifier MUST validate the Date, Contact, and Call-ID headers in the manner described in Section 13.1; recipients that wish to verify Identity signatures MUST support all of the operations described there. It must furthermore ensure that the value of the Date header falls within the validity period of the certificate whose corresponding private key was used to sign the Identity header.
検証はセクション13.1で説明された方法でDate、Contact、およびCall-IDヘッダーを有効にしなければなりません。 Identity署名について確かめたがっている受取人はそこで説明された操作のすべてをサポートしなければなりません。 その上、それは、Dateヘッダーの値が対応する秘密鍵がIdentityヘッダーに署名するのに使用された証明書の有効期間中に下落するのを確実にしなければなりません。
7. Considerations for User Agent
7. ユーザエージェントのための問題
This mechanism can be applied opportunistically to existing SIP deployments; accordingly, it requires no change to SIP user agent behavior in order for it to be effective. However, because this mechanism does not provide integrity protection between the UAC and the authentication service, a UAC SHOULD implement some means of providing this integrity. TLS would be one such mechanism, which is attractive because it MUST be supported by SIP proxy servers, but is potentially problematic because it is a hop-by-hop mechanism. See Section 13.3 for more information about securing the channel between the UAC and the authentication service.
便宜主義的に既存のSIP展開にこのメカニズムを適用できます。 それに従って、有効であるのがそれにおいて、整然としているSIPユーザエージェントの振舞いへの変化を全く必要としません。 しかしながら、このメカニズムが提供しないので、UACと認証サービス、UAC SHOULD道具の間の保全保護にこの保全を提供するいくつかの手段を提供してください。 TLSはそのようなメカニズムの1つでしょう。(SIPプロキシサーバでそれをサポートしなければならないので魅力的ですが、それがホップごとのメカニズムであるので、その1つは潜在的に問題が多いです)。 UACと認証サービスの間のチャンネルを固定することに関する詳しい情報に関してセクション13.3を見てください。
When a UAC sends a request, it MUST accurately populate the From header field with a value corresponding to an identity that it believes it is authorized to claim. In a request, it MUST set the URI portion of its From header to match a SIP, SIPS, or TEL URI AoR that it is authorized to use in the domain (including anonymous URIs, as described in RFC 3323 [3]). In general, UACs SHOULD NOT use the TEL URI form in the From header field (see Section 11).
UACが要求を送るとき、それは要求するそれが認可されているとそれに信じているアイデンティティに対応する値で正確にFromヘッダーフィールドに居住しなければなりません。 要求では、それは、FromヘッダーのURI一部にSIP、SIPS、またはそれがそのドメインで使用するのが認可されるTEL URI AoRを合わせるように設定しなければなりません。(説明されるとしてRFC3323[3])で匿名のURIを含めます。 一般に、UACs SHOULDはFromヘッダーフィールドにTEL URIフォームを使用しません(セクション11を見てください)。
Note that this document defines a number of new 4xx response codes. If user agents support these response codes, they will be able to respond intelligently to Identity-based error conditions.
このドキュメントが多くの新しい4xx応答コードを定義することに注意してください。 ユーザエージェントがこれらの応答コードをサポートすると、彼らは知的にIdentityベースのエラー条件に応じることができるでしょう。
The UAC MUST also be capable of sending requests, including mid-call requests, through an 'outbound' proxy (the authentication service). The best way to accomplish this is using pre-loaded Route headers and loose routing. For a given domain, if an entity that can instantiate the authentication service role is not in the path of dialog-forming
UAC MUST、また、'外国行き'のプロキシ(認証サービス)を通して中間の発呼要求を含む要求は送ることができてください。 これを達成する最も良い方法はプレロードされたRouteヘッダーとゆるいルーティングを使用することです。 与えられたドメインには、役割が認証サービスを例示できる実体であるなら対話形成の経路にありません。
Peterson & Jennings Standards Track [Page 12] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[12ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
requests, identity for mid-dialog requests in the backwards direction cannot be provided.
要求であり、遅れている方向による中間の対話要求のためのアイデンティティを提供できません。
As a recipient of a request, a user agent that can verify signed identities should also support an appropriate user interface to render the validity of identity to a user. User agent implementations SHOULD differentiate signed From header field values from unsigned From header field values when rendering to an end-user the identity of the sender of a request.
また、要求の受取人として、署名しているアイデンティティについて確かめることができるユーザエージェントは、アイデンティティの正当性をユーザに提供するために適切なユーザーインタフェースをサポートするべきです。 要求の送付者のアイデンティティをエンドユーザに提供するとき、SHOULDが差別化するユーザエージェント実装は、未署名のFromヘッダーフィールド値からFromヘッダーフィールドが値であると署名しました。
8. Considerations for Proxy Servers
8. Proxyサーバのための問題
Domain policy may require proxy servers to inspect and verify the identity provided in SIP requests. A proxy server may wish to ascertain the identity of the sender of the message to provide spam prevention or call control services. Even if a proxy server does not act as an authentication service, it MAY validate the Identity header before it makes a forwarding decision for a request. Proxy servers MUST NOT remove or modify an existing Identity or Identity-Info header in a request.
ドメイン方針は、SIP要求に提供されたアイデンティティについて点検して、確かめるためにプロキシサーバを必要とするかもしれません。 プロキシサーバは、スパム防止を前提とするか、またはコントロールをサービスと呼ぶためにメッセージ送信者のアイデンティティを確かめたがっているかもしれません。 プロキシサーバが認証サービスとして機能しないでも、要求のための推進決定をする前にそれはIdentityヘッダーを有効にするかもしれません。 Proxyサーバは、要求で既存のIdentityかIdentity-インフォメーションヘッダーを取り外してはいけませんし、また変更してはいけません。
9. Header Syntax
9. ヘッダー構文
This document specifies two new SIP headers: Identity and Identity- Info. Each of these headers can appear only once in a SIP message. The grammar for these two headers is (following the ABNF [6] in RFC 3261 [1]):
このドキュメントは2個の新しいSIPヘッダーを指定します: アイデンティティとアイデンティティインフォメーション。 これらのヘッダー各人はSIPメッセージに一度だけ現れることができます。 これらの2個のヘッダーのための文法がそうである、(RFC3261[1])でABNF[6]に続きます:
Identity = "Identity" HCOLON signed-identity-digest signed-identity-digest = LDQUOT 32LHEX RDQUOT
アイデンティティは「アイデンティティ」HCOLON署名しているアイデンティティダイジェスト署名しているアイデンティティダイジェスト=LDQUOT 32LHEX RDQUOTと等しいです。
Identity-Info = "Identity-Info" HCOLON ident-info
*( SEMI ident-info-params )
ident-info = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-info-extension = generic-param
"alg"EQUALトークンidentインフォメーションidentインフォメーションalg / identインフォメーション拡張子identインフォメーション「アイデンティティインフォメーション」HCOLON ident-インフォメーションアイデンティティインフォメーション=*(SEMI identインフォメーションparams)LAQUOT absoluteURI RAQUOT identインフォメーションident-インフォメーション=params=alg=拡張子はジェネリック-paramと等しいです。
The signed-identity-digest is a signed hash of a canonical string generated from certain components of a SIP request. To create the contents of the signed-identity-digest, the following elements of a SIP message MUST be placed in a bit-exact string in the order specified here, separated by a vertical line, "|" or %x7C, character:
署名しているアイデンティティダイジェストはSIP要求のある成分から生成された正準なストリングの署名しているハッシュです。 「署名しているアイデンティティダイジェストのコンテンツを作成するために、縦線によってここで指定されて、切り離されたオーダーにSIPメッセージの以下の要素を少し正確なストリングに置かなければなりません」|または、「%x7C、キャラクタ:、」
o The AoR of the UA sending the message, or addr-spec of the From
header field (referred to occasionally here as the 'identity
field').
o メッセージを送るUAのAoR、またはFromヘッダーフィールドのaddr-仕様('アイデンティティ分野'として時折ここに言及されます)。
Peterson & Jennings Standards Track [Page 13] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[13ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
o The addr-spec component of the To header field, which is the AoR
to which the request is being sent.
o The callid from Call-Id header field.
o The digit (1*DIGIT) and method (method) portions from CSeq header
field, separated by a single space (ABNF SP, or %x20). Note that
the CSeq header field allows linear whitespace (LWS) rather than
SP to separate the digit and method portions, and thus the CSeq
header field may need to be transformed in order to be
canonicalized. The authentication service MUST strip leading
zeros from the 'digit' portion of the Cseq before generating the
digest-string.
o The Date header field, with exactly one space each for each SP and
the weekday and month items case set as shown in BNF in RFC 3261.
RFC 3261 specifies that the BNF for weekday and month is a choice
amongst a set of tokens. The RFC 2234 rules for the BNF specify
that tokens are case sensitive. However, when used to construct
the canonical string defined here, the first letter of each week
and month MUST be capitalized, and the remaining two letters must
be lowercase. This matches the capitalization provided in the
definition of each token. All requests that use the Identity
mechanism MUST contain a Date header.
o The addr-spec component of the Contact header field value. If the
request does not contain a Contact header, this field MUST be
empty (i.e., there will be no whitespace between the fourth and
fifth "|" characters in the canonical string).
o The body content of the message with the bits exactly as they are
in the Message (in the ABNF for SIP, the message-body). This
includes all components of multipart message bodies. Note that
the message-body does NOT include the CRLF separating the SIP
headers from the message-body, but does include everything that
follows that CRLF. If the message has no body, then message-body
will be empty, and the final "|" will not be followed by any
additional characters.
o Toヘッダーフィールドのaddr-仕様コンポーネントはシングルスペース(ABNF SP、または%x20)のそばで分離しました。(ヘッダーフィールドは要求が. ○ callidがCall-イドヘッダーフィールド○ ケタ(1*DIGIT)とメソッド(メソッド)部分からCSeqヘッダーフィールドから送ることにされるのであるAoRです)。 SPよりむしろ直線的な空白(LWS)がCSeqヘッダーフィールドでケタとメソッド部分を切り離すことができることに注意してください。そうすれば、その結果、CSeqヘッダーフィールドは、canonicalizedされるように変えられる必要があってもよいです。 ダイジェストストリングを生成する前に、認証サービスはCseqの'ケタ'一部から先行ゼロを剥取らなければなりません。○ Dateヘッダーフィールド、ちょうど1で、項目がケースに入れる各SPのためのそれぞれスペース、平日、および月はRFC3261のBNFに示されるようにセットしました。 RFC3261は、平日、月のためのBNFがトークンのセットの中の選択であると指定します。 BNFのためのRFC2234規則は、トークンが大文字と小文字を区別していると指定します。 しかしながら、ここで定義された正準なストリングを構成するのに使用されると、週と毎月の最初の手紙を大文字で書かなければなりません、そして、残っている2個の手紙が小文字であるに違いありません。 これはそれぞれのトークンの定義に提供された資源化に合っています。 Identityメカニズムを使用するすべての要求がDateヘッダーを含まなければなりません。○ Contactヘッダーのaddr-仕様の部品は値をさばきます。 要求がContactヘッダーを含んでいないなら、この分野はちょうどそれらがメッセージ(一口のためのABNFのメッセージ本体)にあるときビットで. ○ メッセージの(すなわち、空白が全く「|」 正準のキャラクタが結ぶ4番目と5番目の間ないでしょう)ボディー内容を空にすることであるに違いありません。 これは複合メッセージ本体のすべてのコンポーネントを含んでいます。 メッセージ本体がメッセージ本体からSIPヘッダーを分離するCRLFを含んでいませんが、そのCRLFに続くすべてを含んでいることに注意してください。 「メッセージにボディーが全くないと、メッセージ本体は、空であって、決勝になるでしょう」|「どんな添字もあとに続かないでしょう。」
For more information on the security properties of these headers, and why their inclusion mitigates replay attacks, see Section 13 and [5]. The precise formulation of this digest-string is, therefore (following the ABNF [6] in RFC 3261 [1]):
これらのヘッダー、および彼らの包含が反射攻撃を緩和する理由に関するセキュリティ所有地の詳しい情報に関しては、セクション13と[5]を見てください。 したがって、このダイジェストストリングの正確な定式化がそうである、(RFC3261[1])でABNF[6]に続きます:
digest-string = addr-spec "|" addr-spec "|" callid "|"
1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|"
message-body
「ダイジェストストリング=addr-仕様」|「addr-仕様」|"callid"|「1*ケタSPメソッド」|「一口日付」|「[addr-仕様]」|「メッセージ本体」
Note again that the first addr-spec MUST be taken from the From header field value, the second addr-spec MUST be taken from the To header field value, and the third addr-spec MUST be taken from the Contact header field value, provided the Contact header is present in the request.
Fromヘッダーフィールド価値から最初のaddr-仕様を取らなければならなくて、Toヘッダーフィールド価値から2番目のaddr-仕様を取らなければならなくて、Contactヘッダーフィールド価値から3番目のaddr-仕様を取らなければならないことにもう一度注意してください、Contactヘッダーが要求に出席しているなら。
Peterson & Jennings Standards Track [Page 14] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[14ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
After the digest-string is formed, it MUST be hashed and signed with the certificate for the domain. The hashing and signing algorithm is specified by the 'alg' parameter of the Identity-Info header (see below for more information on Identity-Info header parameters). This document defines only one value for the 'alg' parameter: 'rsa-sha1'; further values MUST be defined in a Standards Track RFC, see Section 14.7 for more information. All implementations of this specification MUST support 'rsa-sha1'. When the 'rsa-sha1' algorithm is specified in the 'alg' parameter of Identity-Info, the hash and signature MUST be generated as follows: compute the results of signing this string with sha1WithRSAEncryption as described in RFC 3370 [7] and base64 encode the results as specified in RFC 3548 [8]. A 1024-bit or longer RSA key MUST be used. The result is placed in the Identity header field. For detailed examples of the usage of this algorithm, see Section 10.
ダイジェストストリングが形成された後に、ドメインのためにそれを論じ尽くされて、証明書を契約しなければなりません。 論じ尽くすのと署名アルゴリズムはIdentity-インフォメーションヘッダー(Identity-インフォメーションヘッダーパラメタの詳しい情報に関して以下を見る)の'alg'パラメタによって指定されます。 このドキュメントは'alg'パラメタのために1つの値だけを定義します: 'rsa-sha1'。 さらに、セクション14.7は、詳しい情報に関してStandards Track RFCで値を定義しなければならないのを見ます。 この仕様のすべての実装が'rsa-sha1'をサポートしなければなりません。 'rsa-sha1'アルゴリズムがIdentity-インフォメーションの'alg'パラメタで指定されるとき、以下の通りハッシュと署名を生成しなければなりません: 指定されるとしてRFC3370[7]で説明されるsha1WithRSAEncryptionがあるこのストリングとbase64エンコードが結果であると署名するというRFC3548[8]の結果を計算してください。 1024ビットか、より長いRSAキーを使用しなければなりません。 結果はIdentityヘッダーフィールドに置かれます。 このアルゴリズムの用法の詳細な例に関しては、セクション10を見てください。
The 'absoluteURI' portion of the Identity-Info header MUST contain a URI which dereferences to a resource containing the certificate of the authentication service. All implementations of this specification MUST support the use of HTTP and HTTPS URIs in the Identity-Info header. Such HTTP and HTTPS URIs MUST follow the conventions of RFC 2585 [10], and for those URIs the indicated resource MUST be of the form 'application/pkix-cert' described in that specification. Note that this introduces key lifecycle management concerns; were a domain to change the key available at the Identity-Info URI before a verifier evaluates a request signed by an authentication service, this would cause obvious verifier failures. When a rollover occurs, authentication services SHOULD thus provide new Identity-Info URIs for each new certificate, and SHOULD continue to make older key acquisition URIs available for a duration longer than the plausible lifetime of a SIP message (an hour would most likely suffice).
Identity-インフォメーションヘッダーの'absoluteURI'一部がURIを含まなければなりません。認証サービスの証明書を含むリソースへのどの反参照。 この仕様のすべての実装がIdentity-インフォメーションヘッダーでHTTPとHTTPS URIの使用をサポートしなければなりません。 そのようなHTTPとHTTPS URIはRFC2585[10]のコンベンションに続かなければなりません、そして、示されたリソースはその仕様で説明されたフォーム'pkixアプリケーション/本命'へのそれらのURIのための、ものであるに違いありません。 これが主要なlifecycle管理関心を導入することに注意してください。 検証が認証サービスで署名される要求を評価する前にドメインがIdentity-インフォメーションURIで利用可能なキーを変えるなら、これは明白な検証の故障を引き起こすでしょうに。 ロールオーバーが起こると、その結果、認証サービスSHOULDは新しいIdentity-インフォメーションURIをそれぞれの新しい証明書に供給します、そして、SHOULDはSIPメッセージのもっともらしい生涯より長い間さらに古い主要な獲得を持続時間に利用可能なURIにし続けています(1時間はたぶん十分でしょう)。
The Identity-Info header field MUST contain an 'alg' parameter. No other parameters are defined for the Identity-Info header in this document. Future Standards Track RFCs may define additional Identity-Info header parameters.
Identity-インフォメーションヘッダーフィールドは'alg'パラメタを含まなければなりません。 他のパラメタは全くIdentity-インフォメーションヘッダーのために本書では定義されません。 将来のStandards Track RFCsは追加Identity-インフォメーションヘッダーパラメタを定義するかもしれません。
Peterson & Jennings Standards Track [Page 15] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[15ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
This document adds the following entries to Table 2 of RFC 3261 [1]:
このドキュメントはRFC3261[1]のTable2に以下のエントリーを加えます:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Identity R a o o - o o o
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG------------ ----- ----- --- --- --- --- --- --- アイデンティティR a o o--o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
潜水艦審判INF UPD PRAでない--- --- --- --- --- --- o o o o o o
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Identity-Info R a o o - o o o
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG------------ ----- ----- --- --- --- --- --- --- アイデンティティインフォメーションR a o o--o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
潜水艦審判INF UPD PRAでない--- --- --- --- --- --- o o o o o o
Note, in the table above, that this mechanism does not protect the CANCEL method. The CANCEL method cannot be challenged, because it is hop-by-hop, and accordingly authentication service behavior for CANCEL would be significantly limited. Note as well that the REGISTER method uses Contact header fields in very unusual ways that complicate its applicability to this mechanism, and the use of Identity with REGISTER is consequently a subject for future study, although it is left as optional here for forward-compatibility reasons. The Identity and Identity-Info header MUST NOT appear in CANCEL.
上のテーブルでこのメカニズムがキャンセルメソッドを保護しないことに注意してください。 キャンセルメソッドに挑戦できません、それがホップであることごとにキャンセルのための認証サービスの振舞いはそれに従って、かなり限られているでしょう、したがって。 また、REGISTERメソッドがこのメカニズムへの適用性を複雑にする非常に珍しい方法でContactヘッダーフィールドを使用して、その結果、REGISTERとのIdentityの使用が今後の研究への対象であることに注意してください、それは任意であるとしてここから下位互換理由に外されますが。 IdentityとIdentity-インフォメーションヘッダーはキャンセルに現れてはいけません。
10. Compliance Tests and Examples
10. 適合テストと例
The examples in this section illustrate the use of the Identity header in the context of a SIP transaction. Implementers are advised to verify their compliance with the specification against the following criteria:
このセクションの例はSIPトランザクションの文脈におけるIdentityヘッダーの使用を例証します。 Implementersが以下の評価基準に対して仕様への彼らのコンプライアンスについて確かめるようにアドバイスされます:
o Implementations of the authentication service role MUST generate
identical base64 identity strings to the ones shown in the
Identity headers in these examples when presented with the source
message and utilizing the appropriate supplied private key for the
domain in question.
o Implementations of the verifier role MUST correctly validate the
given messages containing the Identity header when utilizing the
supplied certificates (with the caveat about self-signed
certificates below).
o 認証サービスの役割の実装は、同じbase64のアイデンティティがストリングであるとソースメッセージを与えて、適切な供給された秘密鍵を問題のドメインに利用するときこれらの例のIdentityヘッダーに示されたものに生成しなければなりません。検証の役割のo Implementationsは正しく供給された証明書(以下の自己署名入りの証書の周りに警告がある)を利用するときIdentityヘッダーを含む与えられたメッセージを有効にしなければなりません。
Peterson & Jennings Standards Track [Page 16] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[16ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
Note that the following examples use self-signed certificates, rather than certificates issued by a recognized certificate authority. The use of self-signed certificates for this mechanism is NOT RECOMMENDED, and it appears here only for illustrative purposes. Therefore, in compliance testing, implementations of verifiers SHOULD generate appropriate warnings about the use of self-signed certificates. Also, the example certificates in this section have placed their domain name subject in the subjectAltName field; in practice, certificate authorities may place domain names in other locations in the certificate (see Section 13.4 for more information).
以下の例が認識された認証局によって発行された証明書よりむしろ自己署名入りの証書を使用することに注意してください。 自己署名入りの証書のこのメカニズムの使用はNOT RECOMMENDEDです、そして、それは説明に役立った目的のためだけにここに現れます。 したがって、承諾テストで、検証SHOULDの実装は自己署名入りの証書の使用に関する適切な警告を生成します。 また、このセクションの例の証明書はそれらのドメイン名対象をsubjectAltName分野に置きました。 実際には、認証局は証明書の他の位置にドメイン名を置くかもしれません(詳しい情報に関してセクション13.4を見てください)。
Note that all examples in this section use the 'rsa-sha1' algorithm.
このセクションのすべての例が'rsa-sha1'アルゴリズムを使用することに注意してください。
Bit-exact reference files for these messages and their various transformations are supplied in Appendix B.
Appendix Bでこれらのメッセージとそれらの様々な変換のためのビット正確な参照ファイルを提供します。
10.1. Identity-Info with a Singlepart MIME body
10.1. Singlepart MIMEボディーがあるアイデンティティインフォメーション
Consider the following private key and certificate pair assigned to 'atlanta.example.com' (rendered in OpenSSL format).
'atlanta.example.com'(OpenSSL形式へレンダリングされる)に選任された以下の秘密鍵と証明書組を考えてください。
-----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30 tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H 0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU 6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIC3TCCAkagAwIBAgIBADANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEL MAkGA1UECAwCR0ExEDAOBgNVBAcMB0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAa BgNVBAMME2F0bGFudGEuZXhhbXBsZS5jb20wHhcNMDUxMDI0MDYzNjA2WhcNMDYx MDI0MDYzNjA2WjBZMQswCQYDVQQGEwJVUzELMAkGA1UECAwCR0ExEDAOBgNVBAcM B0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAaBgNVBAMME2F0bGFudGEuZXhhbXBs ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM88wG0dWg+RdX5nqOrU uyB9MQtVanLYFVR98kw8fTosvRwlJA5oh5XMiiPNa2lq4HsjKVkqUCMHl/jb21G6 hSJ50LAwspuVYCpm3p4dakI1knuU41wgTCeaHacBxwqTzcun9Ufe2ABL/jcNChfa yd2diH6DznbY/PCDsQZaynPPAgMBAAGjgbQwgbEwHQYDVR0OBBYEFNmU/MrbVYcE KDr/20WISrG1j1rNMIGBBgNVHSMEejB4gBTZlPzK21WHBCg6/9tFiEqxtY9azaFd pFswWTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkdBMRAwDgYDVQQHDAdBdGxhbnRh
-----RSA秘密鍵を始めてください。----- MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw+rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30; tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk-----終わりのRSA秘密鍵----- -----証明書を始めてください。----- MIIC3TCCAkagAwIBAgIBADANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEL MAkGA1UECAwCR0ExEDAOBgNVBAcMB0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAa BgNVBAMME2F0bGFudGEuZXhhbXBsZS5jb20wHhcNMDUxMDI0MDYzNjA2WhcNMDYx MDI0MDYzNjA2WjBZMQswCQYDVQQGEwJVUzELMAkGA1UECAwCR0ExEDAOBgNVBAcM B0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAaBgNVBAMME2F0bGFudGEuZXhhbXBs ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM88wG0dWg+RdX5nqOrU; uyB9MQtVanLYFVR98kw8fTosvRwlJA5oh5XMiiPNa2lq4HsjKVkqUCMHl/jb21G6 hSJ50LAwspuVYCpm3p4dakI1knuU41wgTCeaHacBxwqTzcun9Ufe2ABL/jcNChfa yd2diH6DznbY/PCDsQZaynPPAgMBAAGjgbQwgbEwHQYDVR0OBBYEFNmU/MrbVYcE KDr/20WISrG1j1rNMIGBBgNVHSMEejB4gBTZlPzK21WHBCg6/9tFiEqxtY9azaFd pFswWTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkdBMRAwDgYDVQQHDAdBdGxhbnRh
Peterson & Jennings Standards Track [Page 17] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[17ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
MQ0wCwYDVQQKDARJRVRGMRwwGgYDVQQDDBNhdGxhbnRhLmV4YW1wbGUuY29tggEA MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADdQYtswBDmTSTq0mt211 7alm/XGFrb2zdbU0vorxRdOZ04qMyrIpXG1LEmnEOgcocyrXRBvq5p6WbZAcEQk0 DsE3Ve0Nc8x9nmvljW7GsMGFCnCuo4ODTf/1lGdVr9DeCzcj10YUQ3MRemDMXhY2 CtDisLWl7SXOORcZAi1oU9w= -----END CERTIFICATE-----
MQ0wCwYDVQQKDARJRVRGMRwwGgYDVQQDDBNhdGxhbnRhLmV4YW1wbGUuY29tggEA MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADdQYtswBDmTSTq0mt211 7alm/XGFrb2zdbU0vorxRdOZ04qMyrIpXG1LEmnEOgcocyrXRBvq5p6WbZAcEQk0 DsE3Ve0Nc8x9nmvljW7GsMGFCnCuo4ODTf/1lGdVr9DeCzcj10YUQ3MRemDMXhY2 CtDisLWl7SXOORcZAi1oU9w=-----終わりの証明書-----
A user of atlanta.example.com, Alice, wants to send an INVITE to bob@biloxi.example.org. She therefore creates the following INVITE request, which she forwards to the atlanta.example.org proxy server that instantiates the authentication service role:
atlanta.example.comのユーザ(アリス)はINVITEを bob@biloxi.example.org に送りたがっています。 したがって、彼女は以下のINVITE要求を作成します:(彼女は認証サービスの役割を例示するatlanta.example.orgプロキシサーバに要求を転送します)。
INVITE sip:bob@biloxi.example.org SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.example.org>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 147
INVITE一口: bob@biloxi.example.org SIP/2.0Via: 一口/2.0/TLS pc33.atlanta.example.com; ブランチ=z9hG4bKnashds8To: ボブ<一口: bob@biloxi.example.org 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 前方へマックスを招待してください: 70 日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒の接触: <一口: alice@pc33.atlanta.example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
0 0IN v=0 o=UserA2890844526 2890844526IN IP4 pc33.atlanta.example.com s=セッションSDP c=IP4 pc33.atlanta.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
When the authentication service receives the INVITE, it authenticates Alice by sending a 407 response. As a result, Alice adds an Authorization header to her request, and resends to the atlanta.example.com authentication service. Now that the service is sure of Alice's identity, it calculates an Identity header for the request. The canonical string over which the identity signature will be generated is the following (note that the first line wraps because of RFC editorial conventions):
認証サービスがINVITEを受けるとき、それは、407応答を送ることによって、アリスを認証します。 その結果、アリスは、彼女へのAuthorizationヘッダーがatlanta.example.com認証サービスに要求して、再送すると言い足します。 サービスがアリスのアイデンティティが確かであるので、それは要求のためにIdentityヘッダーについて計算します。 アイデンティティ署名が生成される正準なストリングは以下(最初の系列がRFCのために編集のコンベンションを包装することに注意する)です:
sip:alice@atlanta.example.com|sip:bob@biloxi.example.org| a84b4c76e66710|314159 INVITE|Thu, 21 Feb 2002 13:02:03 GMT| sip:alice@pc33.atlanta.example.com|v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0
一口: alice@atlanta.example.com |一口: bob@biloxi.example.org | a84b4c76e66710|314159 招待|グリニッジ標準時2002年2月21日木曜日13時2分3秒| 一口: alice@pc33.atlanta.example.com |IN v=0 o=UserA2890844526 2890844526IN IP4 pc33.atlanta.example.com s=セッションSDP c=IP4 pc33.atlanta.example.com tは0 0と等しいです。
Peterson & Jennings Standards Track [Page 18] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[18ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
オーディオの49172RTP/AVP0m=a=rtpmap: 0PCMU/8000
The resulting signature (sha1WithRsaEncryption) using the private RSA key given above, with base64 encoding, is the following:
base64コード化と共に上に与えられた個人的なRSAキーを使用する結果として起こる署名(sha1WithRsaEncryption)は以下です:
ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=
ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=
Accordingly, the atlanta.example.com authentication service will create an Identity header containing that base64 signature string (175 bytes). It will also add an HTTPS URL where its certificate is made available. With those two headers added, the message looks like the following:
それに従って、atlanta.example.com認証サービスはそのbase64署名ストリング(175バイト)を含むIdentityヘッダーを創造するでしょう。 また、それは証明書が利用可能にされるHTTPS URLを加えるでしょう。 それらの2個のヘッダーが加えられている状態で、メッセージは以下に似ています:
INVITE sip:bob@biloxi.example.org SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.example.org>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.example.com>
Identity:
"ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="
Identity-Info: <https://atlanta.example.com/atlanta.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 147
INVITE一口: bob@biloxi.example.org SIP/2.0Via: 一口/2.0/TLS pc33.atlanta.example.com; ブランチ=z9hG4bKnashds8To: ボブ<一口: bob@biloxi.example.org 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 前方へマックスを招待してください: 70 日付: グリニッジ標準時2002年2月21日木曜日13時2分3秒の接触: <一口: alice@pc33.atlanta.example.com 、gt;、アイデンティティ: 「ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=」アイデンティティインフォメーション: <https://atlanta.example.com/atlanta.cer>; alg=rsa-sha1コンテントタイプ: sdp Contentアプリケーション/長さ: 147
v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0IN v=0 o=UserA2890844526 2890844526IN IP4 pc33.atlanta.example.com s=セッションSDP c=IP4 pc33.atlanta.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
atlanta.example.com then forwards the request normally. When Bob receives the request, if he does not already know the certificate of atlanta.example.com, he dereferences the URL in the Identity-Info header to acquire the certificate. Bob then generates the same canonical string given above, from the same headers of the SIP request. Using this canonical string, the signed digest in the Identity header, and the certificate discovered by dereferencing the
そして、通常、atlanta.example.comは要求を転送します。 彼が既にatlanta.example.comの証明書を知らないなら、ボブは要求を受け取って、彼は反参照です。いつ、証明書を入手するIdentity-インフォメーションヘッダーのURL。 そして、ボブはSIP要求の同じヘッダーから上に与えられた同じ正準なストリングを生成します。 この正準なストリングを使用する、Identityヘッダーの署名しているダイジェスト、および証明書は、「反-参照をつけ」ることによって、発見しました。
Peterson & Jennings Standards Track [Page 19] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[19ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
Identity-Info header, Bob can verify that the given set of headers and the message body have not been modified.
アイデンティティインフォメーションヘッダー、ボブは与えられたセットのヘッダーとメッセージ本体が変更されていないことを確かめることができます。
10.2. Identity for a Request with No MIME Body or Contact
10.2. 要求のためのMIME本体も接触のないアイデンティティ
Consider the following private key and certificate pair assigned to "biloxi.example.org".
"biloxi.example.org"に選任された以下の秘密鍵と証明書組を考えてください。
-----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQC/obBYLRMPjskrAqWOiGPAUxI3/m2ti7ix4caqCTAuFX5cLegQ 7nmquLOHfIhxVIqT2f06UA0lOo2NVofK9G7MTkVbVNiyAlLYUDEj7XWLDICf3ZHL 6Fr/+CF7wrQ9r4kv7XiJKxodVCCd/DhCT9Gp+VDoe8HymqOW/KsneriyIwIDAQAB AoGBAJ7fsFIKXKkjWgj8ksGOthS3Sn19xPSCyEdBxfEm2Pj7/Nzzeli/PcOaic0k JALBcnqN2fHEeIGK/9xUBxTufgQYVJqvyHERs6rXX/iT4Ynm9t1905EiQ9ZpHsrI /AMMUYA1QrGgAIHvZLVLzq+9KLDEZ+HQbuCLJXF+6bl0Eb5BAkEA636oMANp0Qa3 mYWEQ2utmGsYxkXSfyBb18TCOwCty0ndBR24zyOJF2NbZS98Lz+Ga25hfIGw/JHK nD9bOE88UwJBANBRSpd4bmS+m48R/13tRESAtHqydNinX0kS/RhwHr7mkHTU3k/M FxQtx34I3GKzaZxMn0A66KS9v/SHdnF+ePECQQCGe7QshyZ8uitLPtZDclCWhEKH qAQHmUEZvUF2VHLrbukLLOgHUrHNa24cILv4d3yaCVUetymNcuyTwhKj24wFAkAO z/jx1EplN3hwL+NsllZoWI58uvu7/Aq2c3czqaVGBbb317sHCYgKk0bAG3kwO3mi 93/LXWT1cdiYVpmBcHDBAkEAmpgkFj+xZu5gWASY5ujv+FCMP0WwaH5hTnXu+tKe PJ3d2IJZKxGnl6itKRN7GeRh9PSK0kZSqGFeVrvsJ4Nopg== -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIC1jCCAj+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJVUzEL MAkGA1UECAwCTVMxDzANBgNVBAcMBkJpbG94aTENMAsGA1UECgwESUVURjEbMBkG A1UEAwwSYmlsb3hpLmV4YW1wbGUuY29tMB4XDTA1MTAyNDA2NDAyNloXDTA2MTAy NDA2NDAyNlowVzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAk1TMQ8wDQYDVQQHDAZC aWxveGkxDTALBgNVBAoMBElFVEYxGzAZBgNVBAMMEmJpbG94aS5leGFtcGxlLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv6GwWC0TD47JKwKljohjwFMS N/5trYu4seHGqgkwLhV+XC3oEO55qrizh3yIcVSKk9n9OlANJTqNjVaHyvRuzE5F W1TYsgJS2FAxI+11iwyAn92Ry+ha//ghe8K0Pa+JL+14iSsaHVQgnfw4Qk/RqflQ 6HvB8pqjlvyrJ3q4siMCAwEAAaOBsTCBrjAdBgNVHQ4EFgQU0Z+RL47W/APDtc5B fSoQXuEFE/wwfwYDVR0jBHgwdoAU0Z+RL47W/APDtc5BfSoQXuEFE/yhW6RZMFcx CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJNUzEPMA0GA1UEBwwGQmlsb3hpMQ0wCwYD VQQKDARJRVRGMRswGQYDVQQDDBJiaWxveGkuZXhhbXBsZS5jb22CAQAwDAYDVR0T BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBiyKHIt8TXfGNfpnJXi5jCizOxmY8Y gln8tyPFaeyq95TGcvTCWzdoBLVpBD+fpRWrX/II5sE6VHbbAPjjVmKbZwzQAtpp P2Fauj28t94ZeDHN2vqzjfnHjCO24kG3Juf2T80ilp9YHcDwxjUFrt86UnlC+yid yaTeusW5Gu7v1g== -----END CERTIFICATE-----
-----RSA秘密鍵を始めてください。----- MIICXgIBAAKBgQC/obBYLRMPjskrAqWOiGPAUxI3/m2ti7ix4caqCTAuFX5cLegQ7nmquLOHfIhxVIqT2f06UA0lOo2NVofK9G7MTkVbVNiyAlLYUDEj7XWLDICf3ZHL6フラン/+CF7wrQ9r4kv7XiJKxodVCCd/DhCT9Gp+VDoe8HymqOW/KsneriyIwIDAQAB AoGBAJ7fsFIKXKkjWgj8ksGOthS3Sn19xPSCyEdBxfEm2Pj7/Nzzeli/PcOaic0k JALBcnqN2fHEeIGK/9xUBxTufgQYVJqvyHERs6rXX/iT4Ynm9t1905EiQ9ZpHsrI/AMMUYA1QrGgAIHvZLVLzq+9KLDEZ+HQbuCLJXF+6bl0Eb5BAkEA636oMANp0Qa3; -----終わりのRSA秘密鍵----- -----証明書を始めてください。----- MIIC1jCCAj+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJVUzEL MAkGA1UECAwCTVMxDzANBgNVBAcMBkJpbG94aTENMAsGA1UECgwESUVURjEbMBkG A1UEAwwSYmlsb3hpLmV4YW1wbGUuY29tMB4XDTA1MTAyNDA2NDAyNloXDTA2MTAy NDA2NDAyNlowVzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAk1TMQ8wDQYDVQQHDAZC; 6HvB8pqjlvyrJ3q4siMCAwEAAaOBsTCBrjAdBgNVHQ4EFgQU0Z+RL47W/ APDtc5B fSoQXuEFE/wwfwYDVR0jBHgwdoAU0Z+RL47W/ APDtc5BfSoQXuEFE/yhW6RZMFcx CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJNUzEPMA0GA1UEBwwGQmlsb3hpMQ0wCwYD VQQKDARJRVRGMRswGQYDVQQDDBJiaWxveGkuZXhhbXBsZS5jb22CAQAwDAYDVR0T BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBiyKHIt8TXfGNfpnJXi5jCizOxmY8Y gln8tyPFaeyq95TGcvTCWzdoBLVpBD+fpRWrX/II5sE6VHbbAPjjVmKbZwzQAtpp P2Fauj28t94ZeDHN2vqzjfnHjCO24kG3Juf2T80ilp9YHcDwxjUFrt86UnlC+ユダヤ人yaTeusW5Gu7v1g=-----終わりの証明書-----
Bob (bob@biloxi.example.org) now wants to send a BYE request to Alice at the end of the dialog initiated in the previous example. He therefore creates the following BYE request, which he forwards to the 'biloxi.example.org' proxy server that instantiates the authentication service role:
ボブ( bob@biloxi.example.org )は現在、前の例で開始された対話の終わりでBYE要求をアリスに送りたがっています。 したがって、彼は以下のBYE要求を作成します:(彼は認証サービスの役割を例示する'biloxi.example.org'プロキシサーバに要求を転送します)。
Peterson & Jennings Standards Track [Page 20] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[20ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
BYE sip:alice@pc33.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf To: Alice <sip:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0
BYE一口: alice@pc33.atlanta.example.com SIP/2.0Via: 一口/2.0/TLS192.0.2.4; ブランチは前方へz9hG4bKnashds10マックスと等しいです: 70 From: ボブ<一口: bob@biloxi.example.org 、gt;、;=a6c85cf To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 231 さようならコンテンツの長さ: 0
When the authentication service receives the BYE, it authenticates Bob by sending a 407 response. As a result, Bob adds an Authorization header to his request, and resends to the biloxi.example.org authentication service. Now that the service is sure of Bob's identity, it prepares to calculate an Identity header for the request. Note that this request does not have a Date header field. Accordingly, the biloxi.example.org will add a Date header to the request before calculating the identity signature. If the Content-Length header were not present, the authentication service would add it as well. The baseline message is thus:
認証サービスがBYEを受けるとき、それは、407応答を送ることによって、ボブを認証します。 そして、その結果、ボブがAuthorizationヘッダーを彼の要求に追加する、biloxi.example.org認証サービスに再送します。 サービスがボブのアイデンティティが確かであるので、それは、要求のためにIdentityヘッダーについて計算するのを準備します。 この要求にはDateヘッダーフィールドがないことに注意してください。 それに従って、アイデンティティ署名について計算する前に、biloxi.example.orgはDateヘッダーを要求に追加するでしょう。 Content-長さのヘッダーが出席していないなら、また、認証サービスはそれを加えるでしょうに。 その結果、基線メッセージは以下の通りです。
BYE sip:alice@pc33.atlanta.example.com SIP/2.0 Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf To: Alice <sip:alice@atlanta.example.com>;tag=1928301774 Date: Thu, 21 Feb 2002 14:19:51 GMT Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0
BYE一口: alice@pc33.atlanta.example.com SIP/2.0Via: 一口/2.0/TLS192.0.2.4; ブランチは前方へz9hG4bKnashds10マックスと等しいです: 70 From: ボブ<一口: bob@biloxi.example.org 、gt;、;=a6c85cf To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、;=1928301774日付:にタグ付けをしてください グリニッジ標準時2002年2月21日木曜日14時19分51秒の呼び出しID: a84b4c76e66710 CSeq: 231 さようならコンテンツの長さ: 0
Also note that this request contains no Contact header field. Accordingly, biloxi.example.org will place no value in the canonical string for the addr-spec of the Contact address. Also note that there is no message body, and accordingly, the signature string will terminate, in this case, with two vertical bars. The canonical string over which the identity signature will be generated is the following (note that the first line wraps because of RFC editorial conventions):
また、この要求がContactヘッダーフィールドを全く含まないことに注意してください。 それに従って、biloxi.example.orgはContactアドレスのaddr-仕様のために値を全く正準なストリングに置かないでしょう。 また、メッセージ本体が全くないことに注意してください。そうすれば、それに従って、署名ストリングは終わるでしょう、この場合、2つの縦棒で。 アイデンティティ署名が生成される正準なストリングは以下(最初の系列がRFCのために編集のコンベンションを包装することに注意する)です:
sip:bob@biloxi.example.org|sip:alice@atlanta.example.com| a84b4c76e66710|231 BYE|Thu, 21 Feb 2002 14:19:51 GMT||
一口: bob@biloxi.example.org |一口: alice@atlanta.example.com | a84b4c76e66710|231 さようなら|グリニッジ標準時2002年2月21日木曜日14時19分51秒||
The resulting signature (sha1WithRsaEncryption) using the private RSA key given above for biloxi.example.org, with base64 encoding, is the following:
biloxi.example.orgのためにbase64コード化と共に上に与えられた個人的なRSAキーを使用する結果として起こる署名(sha1WithRsaEncryption)は以下です:
Peterson & Jennings Standards Track [Page 21] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[21ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=
sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=
Accordingly, the biloxi.example.org authentication service will create an Identity header containing that base64 signature string. It will also add an HTTPS URL where its certificate is made available. With those two headers added, the message looks like the following:
それに従って、biloxi.example.org認証サービスはそのbase64署名ストリングを含むIdentityヘッダーを創造するでしょう。 また、それは証明書が利用可能にされるHTTPS URLを加えるでしょう。 それらの2個のヘッダーが加えられている状態で、メッセージは以下に似ています:
BYE sip:alice@pc33.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf
To: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Date: Thu, 21 Feb 2002 14:19:51 GMT
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Identity:
"sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="
Identity-Info: <https://biloxi.example.org/biloxi.cer>;alg=rsa-sha1
Content-Length: 0
BYE一口: alice@pc33.atlanta.example.com SIP/2.0Via: 一口/2.0/TLS192.0.2.4; ブランチは前方へz9hG4bKnashds10マックスと等しいです: 70 From: ボブ<一口: bob@biloxi.example.org 、gt;、;=a6c85cf To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、;=1928301774日付:にタグ付けをしてください グリニッジ標準時2002年2月21日木曜日14時19分51秒の呼び出しID: a84b4c76e66710 CSeq: 231 さようならのアイデンティティ: 「sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=」アイデンティティインフォメーション: <https://biloxi.example.org/biloxi.cer>; alg=rsa-sha1コンテンツの長さ: 0
biloxi.example.org then forwards the request normally.
そして、通常、biloxi.example.orgは要求を転送します。
11. Identity and the TEL URI Scheme
11. アイデンティティとTEL URI体系
Since many SIP applications provide a Voice over IP (VoIP) service, telephone numbers are commonly used as identities in SIP deployments. In the majority of cases, this is not problematic for the identity mechanism described in this document. Telephone numbers commonly appear in the username portion of a SIP URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). That username conforms to the syntax of the TEL URI scheme (RFC 3966 [13]). For this sort of SIP address-of-record, chicago.example.com is the appropriate signatory.
多くのSIPアプリケーションがボイス・オーバー IP(VoIP)サービスを提供するので、電話番号はアイデンティティとしてSIP展開に一般的に使用されます。 多くの場合、本書では説明されたアイデンティティメカニズムには、これは問題が多くはありません。 電話番号はSIP URIのユーザ名一部に一般的に現れます(例えば、'一口: + 17005551008@chicago.example.com;user は電話と等しいです')。 そのユーザ名はTEL URI体系の構文に従います。(RFC3966[13])。 この種類のSIP記録されている住所のために、chicago.example.comは適切な署名者です。
It is also possible for a TEL URI to appear in the SIP To or From header field outside the context of a SIP or SIPS URI (e.g., 'tel:+17005551008'). In this case, it is much less clear which signatory is appropriate for the identity. Fortunately for the identity mechanism, this form of the TEL URI is more common for the To header field and Request-URI in SIP than in the From header field, since the UAC has no option but to provide a TEL URI alone when the remote domain to which a request is sent is unknown. The local domain, however, is usually known by the UAC, and accordingly it can
また、TEL URIがSIP ToかSIPかSIPS URIの文脈の外におけるFromヘッダーフィールドに現れるのも、可能です(例えば、'tel: +17005551008')。 この場合、アイデンティティに、どの署名者が適切であるかは、あまりそれほど明確ではありません。 幸い、SIPのToヘッダーフィールドとRequest-URIには、アイデンティティメカニズムのために、TEL URIのこのフォームはFromヘッダーフィールドより一般的です、要求が送られる遠く離れたドメインが未知であるときに、UACがTEL URIを提供するのを除いたオプションを全く単独にしないので。 しかしながら、通常、UACは局所領域を知っています、そして、それに従って、それは知ることができます。
Peterson & Jennings Standards Track [Page 22] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[22ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
form a proper From header field containing a SIP URI with a username in TEL URI form. Implementations that intend to send their requests through an authentication service SHOULD put telephone numbers in the From header field into SIP or SIPS URIs whenever possible.
ユーザ名がTEL URIフォームにある状態で、SIP URIを含む適切なFromヘッダーフィールドを形成してください。 可能であるときはいつも、認証サービスSHOULDで彼らの要求を送るつもりである実装がSIPかSIPS URIへのFromヘッダーフィールドに電話番号を入れます。
If the local domain is unknown to a UAC formulating a request, it most likely will not be able to locate an authentication service for its request, and therefore the question of providing identity in these cases is somewhat moot. However, an authentication service MAY sign a request containing a TEL URI in the From header field. This is permitted in this specification strictly for forward compatibility purposes. In the longer-term, it is possible that ENUM [14] may provide a way to determine which administrative domain is responsible for a telephone number, and this may aid in the signing and verification of SIP identities that contain telephone numbers. This is a subject for future work.
要求を定式化するUACにおいて、局所領域が未知であるなら、たぶん要求のための認証サービスの場所を見つけることができないでしょう、そして、したがって、これらの場合における提供のアイデンティティの問題はいくらか論争中です。 しかしながら、認証サービスはFromヘッダーフィールドにおけるTEL URIを含む要求に署名するかもしれません。 これは下位互換目的のためにこの仕様で厳密に受入れられます。 より長い期間で、ENUM[14]がどの管理ドメインが電話番号に原因となるかを決定する方法を提供するのが、可能であり、これは電話番号を含むSIPのアイデンティティの署名と検証で支援されるかもしれません。 これは今後の活動のための対象です。
12. Privacy Considerations
12. プライバシー問題
The identity mechanism presented in this document is compatible with the standard SIP practices for privacy described in RFC 3323 [3]. A SIP proxy server can act both as a privacy service and as an authentication service. Since a user agent can provide any From header field value that the authentication service is willing to authorize, there is no reason why private SIP URIs that contain legitimate domains (e.g., sip:anonymous@example.com) cannot be signed by an authentication service. The construction of the Identity header is the same for private URIs as it is for any other sort of URIs.
RFC3323[3]で説明されたプライバシーにおいて、本書では提示されたアイデンティティメカニズムは一般的なSIP習慣と互換性があります。 SIPプロキシサーバはプライバシーサービスとして認証サービスとして機能できます。 ユーザエージェントが認証サービスが認可しても構わないと思っているどんなFromヘッダーフィールド価値も提供できるので、認証サービスで正統のドメイン(例えば、一口: anonymous@example.com )を含む個人的なSIP URIに署名することができない理由が全くありません。 個人的なURIに、Identityヘッダーの構造はそれがいかなる他の種類のURIのためのものであるのとも同じです。
Note, however, that an authentication service must possess a certificate corresponding to the host portion of the addr-spec of the From header field of any request that it signs; accordingly, using domains like 'anonymous.invalid' will not be possible for privacy services that also act as authentication services. The assurance offered by the usage of anonymous URIs with a valid domain portion is "this is a known user in my domain that I have authenticated, but I am keeping its identity private". The use of the domain 'anonymous.invalid' entails that no corresponding authority for the domain can exist, and as a consequence, authentication service functions are meaningless.
しかしながら、認証サービスには署名するというどんな要求のFromヘッダーフィールドのaddr-仕様のホスト部分にも対応する証明書がなければならないことに注意してください。 それに従って、'anonymous.invalid'のようなドメインを使用するのはまた、認証サービスとして機能するプライバシーサービスに可能にならないでしょう。 有効なドメイン部分がある匿名のURIの用法で提供された保証は「これが私が認証したドメインの知られているユーザですが、私はアイデンティティを個人的に保っています」です。 ドメインへの対応する権威がないのがそうすることができるドメイン'anonymous.invalid'限嗣相続の使用は存在しています、そして、結果として、認証サービス機能は無意味です。
The "header" level of privacy described in RFC 3323 requests that a privacy service alter the Contact header field value of a SIP message. Since the Contact header field is protected by the signature in an Identity header, privacy services cannot be applied after authentication services without a resulting integrity violation.
プライバシーの「ヘッダー」レベルは、RFC3323要求でプライバシーサービスがSIPメッセージのContactヘッダーフィールド価値を変更すると説明しました。 ContactヘッダーフィールドがIdentityヘッダーに署名で保護されるので、認証サービスの後に結果として起こる整合性違反なしでプライバシーサービスを適用できません。
Peterson & Jennings Standards Track [Page 23] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[23ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
RFC 3325 [12] defines the "id" priv-value token, which is specific to the P-Asserted-Identity header. The sort of assertion provided by the P-Asserted-Identity header is very different from the Identity header presented in this document. It contains additional information about the sender of a message that may go beyond what appears in the From header field; P-Asserted-Identity holds a definitive identity for the sender that is somehow known to a closed network of intermediaries that presumably the network will use this identity for billing or security purposes. The danger of this network-specific information leaking outside of the closed network motivated the "id" priv-value token. The "id" priv-value token has no implications for the Identity header, and privacy services MUST NOT remove the Identity header when a priv-value of "id" appears in a Privacy header.
RFC3325[12]は「イド」priv-値のトークンを定義します。(アイデンティティであると断言されたPヘッダーに、それは、特定です)。 アイデンティティであると断言されたPヘッダーによって提供された主張の種類は本書では紹介されたIdentityヘッダーと非常に異なっています。 それはFromヘッダーフィールドに現れることを越えるかもしれないメッセージの送付者に関する追加情報を含んでいます。 アイデンティティであると断言されたPは送付者にとって、決定的なアイデンティティを保持します、すなわち、そんなにおそらく、仲介者が閉じているネットワークにおいてどうにか知られていて、ネットワークが支払いかセキュリティ目的にこのアイデンティティを使用するでしょう。 このネットワーク特有の情報が閉じているネットワークの外で漏れるという危険は「イド」priv-値のトークンを動機づけました。 「イド」priv-値のトークンには、Identityヘッダーのための意味が全くありません、そして、「イド」のpriv-値がPrivacyヘッダーに現れるとき、プライバシーサービスはIdentityヘッダーを取り除いてはいけません。
Finally, note that unlike RFC 3325, the mechanism described in this specification adds no information to SIP requests that has privacy implications.
最終的に、RFC3325と異なって、この仕様で説明されたメカニズムがSIP要求へのプライバシー意味を持っている情報を全く加えないことに注意してください。
13. Security Considerations
13. セキュリティ問題
13.1. Handling of digest-string Elements
13.1. ストリングを消化しているElementsの取り扱い
This document describes a mechanism that provides a signature over the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP requests. While a signature over the From header field would be sufficient to secure a URI alone, the additional headers provide replay protection and reference integrity necessary to make sure that the Identity header will not be used in cut-and-paste attacks. In general, the considerations related to the security of these headers are the same as those given in RFC 3261 for including headers in tunneled 'message/sip' MIME bodies (see Section 23 in particular). The following section details the individual security properties obtained by including each of these header fields within the signature; collectively, this set of header fields provides the necessary properties to prevent impersonation.
このドキュメントはSIP要求のContact、Date、Call-ID、CSeq、To、およびFromヘッダーフィールドの上に署名を供給するメカニズムについて説明します。 Fromヘッダーフィールドの上の署名が単独でURIを保証するために十分であるだろうという間、追加ヘッダーはIdentityヘッダーがカットアンドペースト攻撃に使用されないのを確実にするのに必要な保全を反復操作による保護と参照に提供します。 一般に、これらのヘッダーのセキュリティに関連する問題はトンネルを堀られた'メッセージ/一口'MIME本体にヘッダーを含むようにRFC3261で与えられたものと同じです(特にセクション23を見てください)。 以下のセクションは署名の中にそれぞれのこれらのヘッダーフィールドを含んでいることによって入手された個別的安全保障資産について詳述します。 このセットのヘッダーフィールドは、ものまねを防ぐために必要な資産をまとめて、提供します。
The From header field indicates the identity of the sender of the message, and the SIP address-of-record URI in the From header field is the identity of a SIP user, for the purposes of this document. The To header field provides the identity of the SIP user that this request targets. Providing the To header field in the Identity signature serves two purposes: first, it prevents cut-and-paste attacks in which an Identity header from legitimate request for one user is cut-and-pasted into a request for a different user; second, it preserves the starting URI scheme of the request, which helps prevent downgrade attacks against the use of SIPS.
Fromヘッダーフィールドはメッセージ送信者のアイデンティティを示します、そして、FromヘッダーフィールドにおけるSIP記録されている住所URIはSIPユーザのアイデンティティです、このドキュメントの目的のために。 Toヘッダーフィールドはこの要求が狙うSIPユーザのアイデンティティを提供します。 ToヘッダーフィールドをIdentity署名に提供すると、2つの目的が役立ちます: まず最初に、1人のユーザを求める正統の要求からのIdentityヘッダーが異なったユーザを求める要求にカットであって貼られるカットアンドペースト攻撃を防ぎます。 2番目に、それは要求の始めのURI体系を保存します。(要求はSIPSの使用に対してダウングレード攻撃を防ぐのを助けます)。
Peterson & Jennings Standards Track [Page 24] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[24ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
The Date and Contact headers provide reference integrity and replay protection, as described in RFC 3261, Section 23.4.2. Implementations of this specification MUST NOT deem valid a request with an outdated Date header field (the RECOMMENDED interval is that the Date header must indicate a time within 3600 seconds of the receipt of a message). Implementations MUST also record Call-IDs received in valid requests containing an Identity header, and MUST remember those Call-IDs for at least the duration of a single Date interval (i.e., commonly 3600 seconds). Because a SIP-compliant UA never generates the same Call-ID twice, verifiers can use the Call-ID to recognize cut-and-paste attacks; the Call-ID serves as a nonce. The result of this is that if an Identity header is replayed within the Date interval, verifiers will recognize that it is invalid because of a Call-ID duplication; if an Identity header is replayed after the Date interval, verifiers will recognize that it is invalid because the Date is stale. The CSeq header field contains a numbered identifier for the transaction, and the name of the method of the request; without this information, an INVITE request could be cut- and-pasted by an attacker and transformed into a BYE request without changing any fields covered by the Identity header, and moreover requests within a certain transaction could be replayed in potentially confusing or malicious ways.
DateとContactヘッダーはRFC3261、セクション23.4.2で説明されるように参照保全と反復操作による保護を提供します。 この仕様の実装は時代遅れのDateヘッダーフィールドがある有効なa要求を考えてはいけません(RECOMMENDED間隔によるDateヘッダーがメッセージの領収書の3600秒以内に時間を示さなければならないということです)。 実装は、また、Identityヘッダーを含んでいて、有効な要求に受け取られたCall-IDを記録しなければならなくて、少なくとも単一のDate間隔の持続時間のためにそれらのCall-IDを(すなわち、一般的に3600秒)覚えていなければなりません。 SIP対応することのUAが二度、検証が使用できる同じCall-IDに認識するCall-IDを決して生成しないので、カットアンドペーストは攻撃されます。 Call-IDは一回だけとして機能します。 この結果はIdentityヘッダーがDate間隔中に再演されると、検証が、それがCall-ID複製のために無効であると認めるということです。 IdentityヘッダーがDate間隔の後に再演されると、検証は、Dateが聞き古したであるそれが無効であると認めるでしょう。 CSeqヘッダーフィールドはトランザクションのための番号付の識別子、および要求のメソッドの名前を含んでいます。 そして、この情報がなければ、INVITE要求を切ることができた、-、貼る、攻撃者で変成することで、あるトランザクションの中で潜在的に紛らわしいか悪意がある方法で再演できましたどんな分野も変えることのないBYE要求が、Identityヘッダーでカバーしていて、そのうえ、要求する。
The Contact header field is included to tie the Identity header to a particular user agent instance that generated the request. Were an active attacker to intercept a request containing an Identity header, and cut-and-paste the Identity header field into its own request (reusing the From, To, Contact, Date, and Call-ID fields that appear in the original message), the attacker would not be eligible to receive SIP requests from the called user agent, since those requests are routed to the URI identified in the Contact header field. However, the Contact header is only included in dialog-forming requests, so it does not provide this protection in all cases.
Contactヘッダーフィールドは、要求を生成した特定のユーザエージェントインスタンスにIdentityヘッダーを結ぶために含まれています。 活発な攻撃者がIdentityヘッダーフィールドをそれ自身の要求にIdentityヘッダーを含む要求を妨害して、切って、貼るなら(From、To、Contact、Date、およびオリジナルのメッセージに現れるCall-ID野原を再利用して)、攻撃者は呼ばれたユーザエージェントからSIP要求を受け取る資格がないでしょうに、それらの要求がContactヘッダーフィールドで特定されたURIに発送されるので。 しかしながら、Contactヘッダーが対話を形成する要求で含められているだけであるので、それはこの保護をすべてのケースに供給しません。
It might seem attractive to provide a signature over some of the information present in the Via header field value(s). For example, without a signature over the sent-by field of the topmost Via header, an attacker could remove that Via header and insert its own in a cut-and-paste attack, which would cause all responses to the request to be routed to a host of the attacker's choosing. However, a signature over the topmost Via header does not prevent attacks of this nature, since the attacker could leave the topmost Via intact and merely insert a new Via header field directly after it, which would cause responses to be routed to the attacker's host "on their way" to the valid host, which has exactly the same end result. Although it is possible that an intermediary-based authentication service could guarantee that no Via hops are inserted between the sending user agent and the authentication service, it could not
Viaヘッダーフィールド価値における現在の情報のいくつか上に署名を提供するのは魅力的に思えるかもしれません。 例えば、攻撃者は、発信している上の最上のViaヘッダーの署名分野がなければ、カットアンドペースト攻撃にそのViaヘッダーを移して、それ自身のものを挿入できました。(それは、攻撃者の選ぶことのホストに発送されるという要求へのすべての応答を引き起こすでしょう)。 しかしながら、最上のViaヘッダーの上の署名はこの種の攻撃を防ぎません、攻撃者が最上のViaを完全なままにし、単に、それ直後新しいViaヘッダーフィールド(「途中でまさに同じ結末を持っている有効なホストへの」攻撃者のホストに応答を発送させる)を挿入できたので。 仲介者ベースの認証サービスが、Viaホップが全く送付ユーザエージェントと認証サービスの間に挿入されないのを保証するかもしれないのが、可能ですが、それは可能であることができませんでした。
Peterson & Jennings Standards Track [Page 25] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[25ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
prevent an attacker from adding a Via hop after the authentication service, and thereby preempting responses. It is necessary for the proper operation of SIP for subsequent intermediaries to be capable of inserting such Via header fields, and thus it cannot be prevented. As such, though it is desirable, securing Via is not possible through the sort of identity mechanism described in this document; the best known practice for securing Via is the use of SIPS.
攻撃者が認証サービスの後にViaホップを加えて、その結果、応答を先取りするのを防いでください。 その後の仲介者がそのようなViaヘッダーフィールドを挿入できるのがSIPの適切な操作に必要であり、その結果、それは防ぐことができません。 そういうものとして、それは望ましいのですが、Viaを固定するのは本書では説明されたアイデンティティメカニズムの種類を通して可能ではありません。 Viaを固定するための最もよく知られている習慣はSIPSの使用です。
This mechanism also provides a signature over the bodies of SIP requests. The most important reason for doing so is to protect Session Description Protocol (SDP) bodies carried in SIP requests. There is little purpose in establishing the identity of the user that originated a SIP request if this assurance is not coupled with a comparable assurance over the media descriptors. Note, however, that this is not perfect end-to-end security. The authentication service itself, when instantiated at a intermediary, could conceivably change the SDP (and SIP headers, for that matter) before providing a signature. Thus, while this mechanism reduces the chance that a replayer or man-in-the-middle will modify SDP, it does not eliminate it entirely. Since it is a foundational assumption of this mechanism that the users trust their local domain to vouch for their security, they must also trust the service not to violate the integrity of their message without good reason. Note that RFC 3261, Section 16.6, states that SIP proxy servers "MUST NOT add to, modify, or remove the message body."
また、このメカニズムはSIP要求のボディーの上に署名を提供します。 そうする最も重要な理由はSIP要求で運ばれたSession記述プロトコル(SDP)本体を保護することです。 この保証がメディア記述子の上の匹敵する保証に結びつけられないならSIP要求を溯源したユーザのアイデンティティを確立するのにおいて目的がほとんどありません。 しかしながら、これが終わりから終わりへの完全なセキュリティでないことに注意してください。 仲介者に例示されると認証サービス自体が多分SDPを変えるかもしれない、(そして、SIPヘッダー、さらに言えば)、署名を提供する前に。 したがって、このメカニズムが「再-プレーヤー」か中央の男性がSDPを変更するという可能性を小さくしている間、それはそれを完全に排除しません。 彼らのセキュリティに太鼓判を押すのが、ユーザが彼らの局所領域を信じるというこのメカニズムの基礎的な仮定であるので、また、彼らはもっともな理由なしで彼らのメッセージの保全に違反しないようにサービスを信じなければなりません。 RFC3261(セクション16.6)がそのSIPプロキシサーバを述べることに注意してください、「加えてはいけない、メッセージ本体を変更するか、または取り除いてください、」
In the end analysis, the Identity and Identity-Info headers cannot protect themselves. Any attacker could remove these headers from a SIP request, and modify the request arbitrarily afterwards. However, this mechanism is not intended to protect requests from men-in-the- middle who interfere with SIP messages; it is intended only to provide a way that SIP users can prove definitively that they are who they claim to be. At best, by stripping identity information from a request, a man-in-the-middle could make it impossible to distinguish any illegitimate messages he would like to send from those messages sent by an authorized user. However, it requires a considerably greater amount of energy to mount such an attack than it does to mount trivial impersonations by just copying someone else's From header field. This mechanism provides a way that an authorized user can provide a definitive assurance of his identity that an unauthorized user, an impersonator, cannot.
結局、分析、Identity、およびIdentity-インフォメーションヘッダーは我が身をかばうことができません。 どんな攻撃者も、その後、任意にSIP要求からこれらのヘッダーを取り除いて、要求を変更できました。 しかしながら、このメカニズムが中の男性から要求を保護することを意図しない、-、-干渉する中央はSIPと共に通信します。 SIPユーザが、彼らが主張する人であると決定的に立証できるのが単に道を提供することを意図します。 中央の男性は、認定ユーザによって送られたそれらのメッセージと彼が送りたがっているどんな違法なメッセージも区別するのを不可能に要求からアイデンティティ情報を剥取ることによって、せいぜい、することができるでしょう。 しかしながら、ただ他の誰かのFromヘッダーフィールドをコピーすることによって些細なものまねを仕掛けるのがそのような攻撃を仕掛けるためにそうするよりかなり大きいエネルギー量を必要とします。 このメカニズムは認定ユーザが権限のないユーザ、ものまね役者がそうすることができないという彼のアイデンティティの決定的な保証を提供できる方法を提供します。
One additional respect in which the Identity-Info header cannot protect itself is the 'alg' parameter. The 'alg' parameter is not included in the digest-string, and accordingly, a man-in-the-middle might attempt to modify the 'alg' parameter. However, it is important to note that preventing men-in-the-middle is not the primary impetus for this mechanism. Moreover, changing the 'alg'
Identity-インフォメーションヘッダーが我が身をかばうことができない1つの追加敬意が'alg'パラメタです。 'alg'パラメタはダイジェストストリングで入れられていません、そして、それに従って、中央の男性は'alg'パラメタを変更するのを試みるかもしれません。 しかしながら、中央の男性を防ぐのが、このメカニズムのためのプライマリ起動力でないことに注意するのは重要です。 そのうえ、'alg'を変えること。
Peterson & Jennings Standards Track [Page 26] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[26ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
would at worst result in some sort of bid-down attack, and at best cause a failure in the verifier. Note that only one valid 'alg' parameter is defined in this document and that thus there is currently no weaker algorithm to which the mechanism can be bid down. 'alg' has been incorporated into this mechanism for forward- compatibility reasons in case the current algorithm exhibits weaknesses, and requires swift replacement, in the future.
検証で失敗をある種の下に入札する攻撃で最も悪い結果においてせいぜい引き起こすでしょう。 1つの有効な'alg'パラメタだけが本書では定義されて、その結果、メカニズムを付けることができるどんなより弱いアルゴリズムも現在ないというメモはダウンします。 現在のアルゴリズムが弱点を示して、迅速な交換を必要として、急進的な互換性理由で'alg'をこのメカニズムに組み入れてあります、将来。
13.2. Display-Names and Identity
13.2. ディスプレイ名とアイデンティティ
As a matter of interface design, SIP user agents might render the display-name portion of the From header field of a caller as the identity of the caller; there is a significant precedent in email user interfaces for this practice. As such, it might seem that the lack of a signature over the display-name is a significant omission.
インタフェースデザインの問題として、SIPユーザエージェントは訪問者のアイデンティティとして訪問者のFromヘッダーフィールドのディスプレイ名の部分をレンダリングするかもしれません。 重要な先例がこの習慣のためのメールユーザインタフェースにあります。 そういうものとして、ディスプレイ名の上の署名の不足が重要な省略であるように思えるかもしれません。
However, there are several important senses in which a signature over the display-name does not prevent impersonation. In the first place, a particular display-name, like "Jon Peterson", is not unique in the world; many users in different administrative domains might legitimately claim that name. Furthermore, enrollment practices for SIP-based services might have a difficult time discerning the legitimate display-name for a user; it is safe to assume that impersonators will be capable of creating SIP accounts with arbitrary display-names. The same situation prevails in email today. Note that an impersonator who attempted to replay a message with an Identity header, changing only the display-name in the From header field, would be detected by the other replay protection mechanisms described in Section 13.1.
しかしながら、ディスプレイ名の上の署名がものまねを防がないいくつかの重要な感覚があります。 第一に、「ジョン・ピーターソン」のように、特定のディスプレイ名は世界でユニークではありません。 異なった管理ドメインの多くのユーザが合法的にその名前を要求するかもしれません。 その上、SIPベースのサービスのための登録練習には、ユーザのために正統のディスプレイ名について明察する困難な時があるかもしれません。 ものまね役者が任意のディスプレイ名とのSIPアカウントを作成できると仮定するのは安全です。 同じ状況は今日、メールで広がっています。 Fromヘッダーフィールドにおけるディスプレイ名だけを変えて、Identityヘッダーと共にメッセージを再演するのを試みたものまね役者がセクション13.1で説明された他の反復操作による保護メカニズムによって検出されることに注意してください。
Of course, an authentication service can enforce policies about the display-name even if the display-name is not signed. The exact mechanics for creating and operationalizing such policies is outside the scope of this document. The effect of this policy would not be to prevent impersonation of a particular unique identifier like a SIP URI (since display-names are not unique identifiers), but to allow a domain to manage the claims made by its users. If such policies are enforced, users would not be free to claim any display-name of their choosing. In the absence of a signature, man-in-the-middle attackers could conceivably alter the display-names in a request with impunity. Note that the scope of this specification is impersonation attacks, however, and that a man-in-the-middle might also strip the Identity and Identity-Info headers from a message.
もちろん、ディスプレイ名が調印されないでも、認証サービスはディスプレイ名に関する方針を実施できます。 そのような方針を作成して、operationalizingするための正確な整備士はこのドキュメントの範囲の外にいます。 ドメインがユーザによってされたクレームを管理するのを許容するために、この方針の効果はSIP URI(ディスプレイ名がユニークな識別子でないので)のような特定のユニークな識別子のものまねを防ぐためにあるだろうというのではなく、あります。 そのような方針が励行されるなら、ユーザは自由に彼らが選ぶどんなディスプレイ名も要求できないでしょう。 署名がないとき、中央の男性攻撃者は多分要求におけるディスプレイ名を罰を受けずに変更できました。 しかしながら、この仕様の範囲がものまね攻撃であり、また、中央の男性がメッセージからIdentityとIdentity-インフォメーションヘッダーを裸にするかもしれないことに注意してください。
There are many environments in which policies regarding the display- name aren't feasible. Distributing bit-exact and internationalizable display-names to end-users as part of the enrollment or registration process would require mechanisms that are not explored in this
ディスプレイ名に関する方針が可能でない多くの環境があります。 登録か登録手続の一部がこれで探られないメカニズムを必要とするだろう、そうしながら、ビット正確で国際化可能なディスプレイ名をエンドユーザに分配します。
Peterson & Jennings Standards Track [Page 27] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[27ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
document. In the absence of policy enforcement regarding domain names, there are conceivably attacks that an adversary could mount against SIP systems that rely too heavily on the display-name in their user interface, but this argues for intelligent interface design, not changes to the mechanisms. Relying on a non-unique identifier for identity would ultimately result in a weak mechanism.
記録します。 ドメイン名に関する方針実施がないとき、敵がそれらのユーザーインタフェースであまりに大いにディスプレイ名を当てにするSIPシステムに対して仕掛けることができた攻撃が多分ありますが、メカニズムへの変化ではなく、知的なインタフェースデザインがこれは賛成の議論をされます。アイデンティティのための非ユニークな識別子を当てにすると、弱いメカニズムは結局、もたらされるでしょう。
13.3. Securing the Connection to the Authentication Service
13.3. 認証サービスに接続を保証します。
The assurance provided by this mechanism is strongest when a user agent forms a direct connection, preferably one secured by TLS, to an intermediary-based authentication service. The reasons for this are twofold:
ユーザエージェントがダイレクト接続、望ましくはTLSによって機密保護されたものを形成するとき、このメカニズムによって提供される中で保証は最も強いです、仲介者ベースの認証サービスに。 この理由は二つです:
If a user does not receive a certificate from the authentication
service over this TLS connection that corresponds to the expected
domain (especially when the user receives a challenge via a
mechanism such as Digest), then it is possible that a rogue server
is attempting to pose as an authentication service for a domain
that it does not control, possibly in an attempt to collect shared
secrets for that domain.
ユーザが認証サービスから証明書を予想されたドメインに文通するこのTLS接続の上に受け取らないなら(特にユーザがDigestなどのメカニズムで挑戦を受けるとき)、制御しないのは凶暴なサーバが、ドメインのための認証サービスのふりをするのを試みているのが可能です、そのドメインのための共有秘密キーを集めることによると試みで。
Without TLS, the various header field values and the body of the
request will not have integrity protection when the request
arrives at an authentication service. Accordingly, a prior
legitimate or illegitimate intermediary could modify the message
arbitrarily.
要求が認証サービスに到達するとき、TLSがなければ、様々なヘッダーフィールド値と要求のボディーには保全保護がないでしょう。 それに従って、先の正統の、または、違法な仲介者は任意にメッセージを変更できました。
Of these two concerns, the first is most material to the intended scope of this mechanism. This mechanism is intended to prevent impersonation attacks, not man-in-the-middle attacks; integrity over the header and bodies is provided by this mechanism only to prevent replay attacks. However, it is possible that applications relying on the presence of the Identity header could leverage this integrity protection, especially body integrity, for services other than replay protection.
これらの2回の関心では、1番目はこのメカニズムの意図している範囲へのほとんどの材料です。 このメカニズムが介入者攻撃ではなく、ものまね攻撃を防ぐことを意図します。 このメカニズムでヘッダーとボディーの上の保全を提供しますが、反射攻撃を防ぎます。 しかしながら、Identityヘッダーの存在を当てにするアプリケーションが、この保全が保護であると利用するかもしれないのは、可能です、特にボディー保全、反復操作による保護以外のサービスのために。
Accordingly, direct TLS connections SHOULD be used between the UAC and the authentication service whenever possible. The opportunistic nature of this mechanism, however, makes it very difficult to constrain UAC behavior, and moreover there will be some deployment architectures where a direct connection is simply infeasible and the UAC cannot act as an authentication service itself. Accordingly, when a direct connection and TLS are not possible, a UAC should use the SIPS mechanism, Digest 'auth-int' for body integrity, or both when it can. The ultimate decision to add an Identity header to a
それに従って、TLS接続SHOULDを向けてください。可能であるときはいつも、UACと認証サービスの間で使用されてください。 しかしながら、このメカニズムの便宜主義的な本質で、UACの振舞いを抑制するのは非常に難しくなります、そして、そのうえ、いくつかの展開アーキテクチャがダイレクト接続が単に実行不可能であるところにあるでしょう、そして、UACは認証サービス自体として機能できません。 使用できるとき、ダイレクト接続とTLSが可能でないときに、それに従って、UACはSIPSメカニズム、ボディー保全のためのDigest'auth-int'、または両方を使用するはずです。 Identityヘッダーをaに加えるという最終決定
Peterson & Jennings Standards Track [Page 28] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[28ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
request lies with the authentication service, of course; domain policy must identify those cases where the UAC's security association with the authentication service is too weak.
認証サービスがある偽りを要求してください、もちろん。 ドメイン方針は認証サービスとのUACのセキュリティ協会が弱過ぎるそれらのケースを特定しなければなりません。
13.4. Domain Names and Subordination
13.4. ドメイン名と従属
When a verifier processes a request containing an Identity-Info header, it must compare the domain portion of the URI in the From header field of the request with the domain name that is the subject of the certificate acquired from the Identity-Info header. While it might seem that this should be a straightforward process, it is complicated by two deployment realities. In the first place, certificates have varying ways of describing their subjects, and may indeed have multiple subjects, especially in 'virtual hosting' cases where multiple domains are managed by a single application. Secondly, some SIP services may delegate SIP functions to a subordinate domain and utilize the procedures in RFC 3263 [4] that allow requests for, say, 'example.com' to be routed to 'sip.example.com'. As a result, a user with the AoR 'sip:jon@example.com' may process its requests through a host like 'sip.example.com', and it may be that latter host that acts as an authentication service.
検証がIdentity-インフォメーションヘッダーを含む要求を処理するとき、それはIdentity-インフォメーションヘッダーから入手された証明書の対象であるドメイン名に要求のFromヘッダーフィールドにおけるURIのドメイン部分をたとえなければなりません。 これが簡単なプロセスであるように思えているかもしれない間、それは2つの展開現実によって複雑にされます。 第一に、証明書は、それらの対象について説明する異なった方法を持っていて、本当に、複数の対象を持っているかもしれません、特に複数のドメインがただ一つのアプリケーションで管理される'仮想の接待'場合で。 第二に、いくつかのSIPサービスが、SIP機能を下位のドメインへ代表として派遣して、RFC3263[4]のたとえば、'example.com'が'sip.example.com'に発送されるという要求を許す手順を利用するかもしれません。 結果、AoR'一口をもっているユーザ: jon@example.com が多分''sip.example.comのようなホストを通して要求を処理するかもしれない'という後者のホストとして、それは認証サービスとして務めます。
To meet the second of these problems, a domain that deploys an authentication service on a subordinate host MUST be willing to supply that host with the private keying material associated with a certificate whose subject is a domain name that corresponds to the domain portion of the AoRs that the domain distributes to users. Note that this corresponds to the comparable case of routing inbound SIP requests to a domain. When the NAPTR and SRV procedures of RFC 3263 are used to direct requests to a domain name other than the domain in the original Request-URI (e.g., for 'sip:jon@example.com', the corresponding SRV records point to the service 'sip1.example.org'), the client expects that the certificate passed back in any TLS exchange with that host will correspond exactly with the domain of the original Request-URI, not the domain name of the host. Consequently, in order to make inbound routing to such SIP services work, a domain administrator must similarly be willing to share the domain's private key with the service. This design decision was made to compensate for the insecurity of the DNS, and it makes certain potential approaches to DNS-based 'virtual hosting' unsecurable for SIP in environments where domain administrators are unwilling to share keys with hosting services.
これらの問題の2番目を満たすために、下位のホストの上で認証サービスを配布するドメインは、材料が対象がドメインがユーザに分配するAoRsのドメイン一部に対応するドメイン名である証明書に関連づけた個人的な合わせることをそのホストに提供しても構わないと思っているに違いありません。 これが本国行きのSIPがドメインに要求するルーティングの匹敵するケースに対応することに注意してください。 RFC3263のNAPTRとSRV手順がオリジナルのRequest-URIにおけるドメイン以外のドメイン名に要求を向けるのに用いられるとき(例えば、'一口: jon@example.com 'に関して、対応するSRV記録はサービス'sip1.example.org'を示します)、クライアントは、そのホストと共にどんなTLS交換でも戻された証明書がちょうどホストのドメイン名ではなく、オリジナルのRequest-URIのドメインに一致すると予想します。 その結果、そのようなSIPサービスへのインバウンド・ルーティングを働かせるように、ドメイン管理者は、ドメインの秘密鍵をサービスと共有しても構わないと同様に思っているに違いありません。 DNSの不安定を補うのをこのデザイン決定をしました、そして、それはドメイン管理者がホスティングサービスとキーを共有したがっていないところでDNSベースの'仮想の接待'へのあるポテンシャル法がSIPのために環境で「非-手に入れられ」されるのをします。
A verifier MUST evaluate the correspondence between the user's identity and the signing certificate by following the procedures defined in RFC 2818 [11], Section 3.1. While RFC 2818 deals with the use of HTTP in TLS, the procedures described are applicable to
検証は、RFC2818[11](セクション3.1)で定義された手順に従うことでユーザのアイデンティティと署名証明書との通信を評価しなければなりません。 適切な状態でTLSにおけるHTTPの使用と共に、説明された手順があるというRFC2818取引をゆったり過ごしてください。
Peterson & Jennings Standards Track [Page 29] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[29ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
verifying identity if one substitutes the "hostname of the server" in HTTP for the domain portion of the user's identity in the From header field of a SIP request with an Identity header.
1であるなら本人であることを確かめるのはIdentityヘッダーによるSIP要求のFromヘッダーフィールドにおけるユーザのアイデンティティのドメイン部分にHTTPにおける「サーバに関するホスト名」を代入します。
Because the domain certificates that can be used by authentication services need to assert only the hostname of the authentication service, existing certificate authorities can provide adequate certificates for this mechanism. However, not all proxy servers and user agents will be able to support the root certificates of all certificate authorities, and moreover there are some significant differences in the policies by which certificate authorities issue their certificates. This document makes no recommendations for the usage of particular certificate authorities, nor does it describe any particular policies that certificate authorities should follow, but it is anticipated that operational experience will create de facto standards for authentication services. Some federations of service providers, for example, might only trust certificates that have been provided by a certificate authority operated by the federation. It is strongly RECOMMENDED that self-signed domain certificates should not be trusted by verifiers, unless some previous key exchange has justified such trust.
認証サービスで使用できるドメイン証明書が、認証サービスに関するホスト名だけについて断言する必要があるので、既存の認証局はこのメカニズムのための適切な証明書を提供できます。 しかしながら、すべてのプロキシサーバとどんなユーザエージェントもすべての認証局に関するルート証明書をサポートすることができないでしょう、そして、そのうえ、認証局がそれらの証明書を発行する方針のいくつかの著しい違いがあります。 このドキュメントは特定の認証局の用法のための推薦状を全くしません、そして、認証局が従うべきであるどんな特定の方針も説明しません、しかし、運用経験が認証サービスのためのデファクトスタンダードを作成すると予期されます。 例えば、サービスプロバイダーのいくつかの連邦が連邦によって運用された認証局によって提供された証明書を信じるだけであるかもしれません。 強く、検証は自己にドメイン証明書に署名したRECOMMENDEDを信じるはずがありません、前の何らかの主要な交換がそのような信頼を正当化していない場合ことです。
For further information on certificate security and practices, see RFC 3280 [9]. The Security Considerations of RFC 3280 are applicable to this document.
証明書セキュリティと習慣の詳細に関しては、RFC3280[9]を見てください。 RFC3280のSecurity Considerationsはこのドキュメントに適切です。
13.5. Authorization and Transitional Strategies
13.5. 承認と過渡的な戦略
Ultimately, the worth of an assurance provided by an Identity header is limited by the security practices of the domain that issues the assurance. Relying on an Identity header generated by a remote administrative domain assumes that the issuing domain used its administrative practices to authenticate its users. However, it is possible that some domains will implement policies that effectively make users unaccountable (e.g., ones that accept unauthenticated registrations from arbitrary users). The value of an Identity header from such domains is questionable. While there is no magic way for a verifier to distinguish "good" from "bad" domains by inspecting a SIP request, it is expected that further work in authorization practices could be built on top of this identity solution; without such an identity solution, many promising approaches to authorization policy are impossible. That much said, it is RECOMMENDED that authentication services based on proxy servers employ strong authentication practices such as token-based identifiers.
結局、Identityヘッダーによって提供された保証の価値は保証を発行するドメインのセキュリティ実践によって制限されます。 遠く離れた管理ドメインによって生成されたIdentityヘッダーを当てにするのは、発行ドメインがユーザを認証するのに管理習慣を使用したと仮定します。 しかしながら、いくつかのドメインが事実上ユーザを責任があるようにしない政策を実施するのは(例えば受け入れるのは任意のユーザから登録証明書を非認証しました)、可能です。 そのようなドメインからのIdentityヘッダーの値は疑わしいです。 検証が「悪い」ドメインとSIP要求を点検することによって「利益」を区別するどんな魔法の方法もない間、このアイデンティティソリューションの上で承認習慣におけるさらなる仕事を組み込むことができたと予想されます。 そのようなアイデンティティソリューションがなければ、承認方針への多くの有望なアプローチが不可能です。 それだけは言って、プロキシサーバに基づく認証サービスがトークンベースの識別子などの強い認証練習を使うのは、RECOMMENDEDです。
One cannot expect the Identity and Identity-Info headers to be supported by every SIP entity overnight. This leaves the verifier in a compromising position; when it receives a request from a given SIP
人は、IdentityとIdentity-インフォメーションヘッダーが夜通しあらゆるSIP実体によって支えられることを期待できません。 これは評判を落とすような位置に検証を残します。 それが与えられたSIPから要求を受け取るとき
Peterson & Jennings Standards Track [Page 30] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[30ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
user, how can it know whether or not the sender's domain supports Identity? In the absence of ubiquitous support for identity, some transitional strategies are necessary.
ユーザ、それは送付者のドメインがIdentityをサポートするかどうかをどうしたら知ることができますか? アイデンティティの遍在しているサポートがないとき、いくつかの過渡的な戦略が必要です。
A verifier could remember when it receives a request from a domain
that uses Identity, and in the future, view messages received from
that domain without Identity headers with skepticism.
検証は、それがIdentityを使用するドメイン、および未来(そのドメインから懐疑を伴うIdentityヘッダーなしで受け取られた視点メッセージ)にいつ要求を受け取るかを覚えているかもしれません。
A verifier could query the domain through some sort of callback
system to determine whether or not it is running an authentication
service. There are a number of potential ways in which this could
be implemented; use of the SIP OPTIONS method is one possibility.
This is left as a subject for future work.
検証は、それが認証サービスを実行しているかどうか決定するためにある種のコールバックシステムを通してドメインについて質問するかもしれません。 これを実装することができた多くの潜在的方法があります。 SIP OPTIONSメソッドの使用は1つの可能性です。 これは今後の活動のための対象として残されます。
In the long term, some sort of identity mechanism, either the one documented in this specification or a successor, must become mandatory-to-use for the SIP protocol; that is the only way to guarantee that this protection can always be expected by verifiers.
長期で、ある種のアイデンティティメカニズム(この仕様に記録されたものか後継者のどちらか)が、SIPプロトコルのために使用するために義務的にならなければなりません。 それは検証がいつもこの保護を予想できるのを保証する唯一の方法です。
Finally, it is worth noting that the presence or absence of the Identity headers cannot be the sole factor in making an authorization decision. Permissions might be granted to a message on the basis of the specific verified Identity or really on any other aspect of a SIP request. Authorization policies are outside the scope of this specification, but this specification advises any future authorization work not to assume that messages with valid Identity headers are always good.
最終的に、Identityヘッダーの存在か不在が承認決定をする唯一の要素であるはずがないことに注意する価値があります。 許容は本当に特定の確かめられたIdentityに基づいたメッセージかSIP要求のいかなる他の局面の上でも承諾されるかもしれません。 この仕様の範囲の外に承認方針がありますが、この仕様は、どんな未来にも承認仕事が、有効なIdentityヘッダーがあるメッセージがいつも良いと仮定しないようにアドバイスします。
14. IANA Considerations
14. IANA問題
This document requests changes to the header and response-code sub- registries of the SIP parameters IANA registry, and requests the creation of two new registries for parameters for the Identity-Info header.
このドキュメントは、SIPパラメタIANA登録のヘッダーと応答コードサブ登録への変化を要求して、Identity-インフォメーションヘッダーへのパラメタのために2つの新しい登録の作成を要求します。
14.1. Header Field Names
14.1. ヘッダーフィールド名
This document specifies two new SIP headers: Identity and Identity- Info. Their syntax is given in Section 9. These headers are defined by the following information, which has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントは2個の新しいSIPヘッダーを指定します: アイデンティティとアイデンティティインフォメーション。 セクション9でそれらの構文を与えます。 これらのヘッダーは以下の情報によって定義されます。(それは、 http://www.iana.org/assignments/sip-parameters の下にサブ登録しているヘッダーに加えられます)。
Header Name: Identity
Compact Form: y
Header Name: Identity-Info
Compact Form: n
ヘッダー名: アイデンティティコンパクト形: yヘッダー名: アイデンティティインフォメーションコンパクト形: n
Peterson & Jennings Standards Track [Page 31] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[31ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
14.2. 428 'Use Identity Header' Response Code
14.2. 428 'アイデンティティヘッダーを使用してください'という応答コード
This document registers a new SIP response code, which is described in Section 6. It is sent when a verifier receives a SIP request that lacks an Identity header in order to indicate that the request should be re-sent with an Identity header. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントは新しいSIP応答コードを示します。(それは、セクション6で説明されます)。 検証が要求がIdentityヘッダーと共に再送されるべきであるのを示すためにIdentityヘッダーを欠いているSIP要求を受け取るとき、それを送ります。 この応答コードは以下の情報によって定義されます。( http://www.iana.org/assignments/sip-parameters の下にサブ登録しているメソッドと応答コードにそれを、追加してあります)。
Response Code Number: 428
Default Reason Phrase: Use Identity Header
応答コード番号: 428デフォルト理由句: アイデンティティヘッダーを使用してください。
14.3. 436 'Bad Identity-Info' Response Code
14.3. 436 '悪いアイデンティティインフォメーション'応答コード
This document registers a new SIP response code, which is described in Section 6. It is used when the Identity-Info header contains a URI that cannot be dereferenced by the verifier (either the URI scheme is unsupported by the verifier, or the resource designated by the URI is otherwise unavailable). This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントは新しいSIP応答コードを示します。(それは、セクション6で説明されます)。 Identity-インフォメーションヘッダーが検証で「反-参照をつけ」ることができないURIを含むとき(URI体系が検証でサポートされないか、またはそうでなければ、URIによって指定されたリソースは入手できません)、それは使用されています。 この応答コードは以下の情報によって定義されます。( http://www.iana.org/assignments/sip-parameters の下にサブ登録しているメソッドと応答コードにそれを、追加してあります)。
Response Code Number: 436
Default Reason Phrase: Bad Identity-Info
応答コード番号: 436デフォルト理由句: 悪いアイデンティティインフォメーション
14.4. 437 'Unsupported Certificate' Response Code
14.4. 437 'サポートされない証明書'応答コード
This document registers a new SIP response code, which is described in Section 6. It is used when the verifier cannot validate the certificate referenced by the URI of the Identity-Info header, because, for example, the certificate is self-signed, or signed by a root certificate authority for whom the verifier does not possess a root certificate. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントは新しいSIP応答コードを示します。(それは、セクション6で説明されます)。 それは、検証が例えば、証明書が自己に署名されるのでIdentity-インフォメーションヘッダーのURIによって参照をつけられる証明書を有効にすることができないなら使用されるか、または検証にはルート証明書がないルート証明書権威によって署名されます。 この応答コードは以下の情報によって定義されます。( http://www.iana.org/assignments/sip-parameters の下にサブ登録しているメソッドと応答コードにそれを、追加してあります)。
Response Code Number: 437
Default Reason Phrase: Unsupported Certificate
応答コード番号: 437デフォルト理由句: サポートされない証明書
Peterson & Jennings Standards Track [Page 32] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[32ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
14.5. 438 'Invalid Identity Header' Response Code
14.5. 438 '無効のアイデンティティヘッダー'応答コード
This document registers a new SIP response code, which is described in Section 6. It is used when the verifier receives a message with an Identity signature that does not correspond to the digest-string calculated by the verifier. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントは新しいSIP応答コードを示します。(それは、セクション6で説明されます)。 検証が検証によって計算されたダイジェストストリングと食い違っているIdentity署名でメッセージを受け取るとき、それは使用されています。 この応答コードは以下の情報によって定義されます。( http://www.iana.org/assignments/sip-parameters の下にサブ登録しているメソッドと応答コードにそれを、追加してあります)。
Response Code Number: 438
Default Reason Phrase: Invalid Identity Header
応答コード番号: 438デフォルト理由句: 無効のアイデンティティヘッダー
14.6. Identity-Info Parameters
14.6. アイデンティティインフォメーションパラメタ
The IANA has created a new registry for Identity-Info headers. This registry is to be prepopulated with a single entry for a parameter called 'alg', which describes the algorithm used to create the signature that appears in the Identity header. Registry entries must contain the name of the parameter and the specification in which the parameter is defined. New parameters for the Identity-Info header may be defined only in Standards Track RFCs.
IANAはIdentity-インフォメーションヘッダーのための新しい登録を作成しました。 この登録はIdentityヘッダーに現れる署名を作成するのに使用されるアルゴリズムを説明する'alg'と呼ばれるパラメタのための単一のエントリーを前もって置いておかれることになっています。 登録エントリーはパラメタが定義されるパラメタと仕様の名前を含まなければなりません。 Identity-インフォメーションヘッダーへの新しいパラメタはStandards Track RFCsだけで定義されるかもしれません。
14.7. Identity-Info Algorithm Parameter Values
14.7. アイデンティティインフォメーションアルゴリズムパラメタ値
The IANA has created a new registry for Identity-Info 'alg' parameter values. This registry is to be prepopulated with a single entry for a value called 'rsa-sha1', which describes the algorithm used to create the signature that appears in the Identity header. Registry entries must contain the name of the 'alg' parameter value and the specification in which the value is described. New values for the 'alg' parameter may be defined only in Standards Track RFCs.
IANAはIdentity-インフォメーション'alg'パラメタ値のための新しい登録を作成しました。 この登録はIdentityヘッダーに現れる署名を作成するのに使用されるアルゴリズムを説明する'rsa-sha1'と呼ばれる値のための単一のエントリーを前もって置いておかれることになっています。 登録エントリーは'alg'パラメタ価値と値が説明される仕様の名前を含まなければなりません。 'alg'パラメタのための新しい値はStandards Track RFCsだけで定義されるかもしれません。
Peterson & Jennings Standards Track [Page 33] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[33ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
Appendix A. Acknowledgements
付録A.承認
The authors would like to thank Eric Rescorla, Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Mark Watson, Henry Sinnreich, Alan Johnston, Patrik Faltstrom, Paul Kyzviat, Adam Roach, John Elwell, Aki Niemi, and Jim Schaad for their comments. Jonathan Rosenberg provided detailed fixes to innumerable sections of the document. The bit-archive presented in Appendix B follows the pioneering example of RFC 4475 [16]. Thanks to Hans Persson and Tao Wan for thorough nit reviews.
作者は彼らのコメントについてエリック・レスコラ、Rohanマーイ、ロバート・スパークス、ジョナサン・ローゼンバーグ、マーク・ワトソン、ヘンリーSinnreich、アラン・ジョンストン、パトリクFaltstrom、ポールKyzviat、アダム・ローチ、ジョン・エルウェル、アキNiemi、およびジムSchaadに感謝したがっています。 ジョナサン・ローゼンバーグはドキュメントの無数のセクションに詳細なフィックスを供給しました。 Appendix Bに提示されたビットアーカイブはRFC4475[16]の先駆けている例に倣っています。 徹底的な夜のレビューをハンス・ペルソンとタオWanをありがとうございます。
Appendix B. Bit-Exact Archive of Examples of Messages
メッセージに関する例の付録のB.のビット正確なアーカイブ
The following text block is an encoded, gzip-compressed TAR archive of files that represent the transformations performed on the examples of messages discussed in Section 10. It includes for each example:
以下のテキストブロックはセクション10で議論したメッセージに関する例に実行された変換を表すファイルのコード化されて、gzipによって圧縮されたTARアーカイブです。 それは各例のために以下を含んでいます。
o (foo).message: the original message
o (foo).canonical: the canonical string constructed from that
message
o (foo).sha1: the SHA1 hash of the canonical string (hexadecimal)
o (foo).signed: the RSA-signed SHA1 hash of the canonical string
(binary)
o (foo).signed.enc: the base64 encoding of the RSA-signed SHA1 hash
of the canonical string as it would appear in the request
o (foo).identity: the original message with the Identity and
Identity-Info headers added
o (foo).message: オリジナルのメッセージo(foo).canonical: 正準なストリングはそのメッセージからo(foo).sha1を組み立てました: 正準なストリング(16進)o(foo).signedのSHA1ハッシュ: 正準なストリング(バイナリー)o(foo).signed.encのRSAによって署名されたSHA1ハッシュ: それとしての正準なストリングのRSAによって署名されたSHA1ハッシュのbase64コード化は要求o(foo).identityに現れるでしょう: IdentityとIdentity-インフォメーションヘッダーが加えられているオリジナルのメッセージ
Also included in the archive are two public key/certificate pairs, for atlanta.example.com and biloxi.example.org, respectively, including:
また、アーカイブに含まれているのは、それぞれである:atlanta.example.comとbiloxi.example.orgのための2公開鍵/証明書組です。
o (foo).cer: the certificate of the domain
o (foo).privkey: the private key of the domain
o (foo).pubkey: the public key of the domain, extracted from the
cert file for convenience
o (foo).cer: ドメインo(foo).privkeyの証明書: ドメインo(foo).pubkeyの秘密鍵: 便宜のための本命ファイルから抽出されたドメインの公開鍵
To recover the compressed archive file intact, the text of this document may be passed as input to the following Perl script (the output should be redirected to a file or piped to "tar -xzvf -").
完全な状態で圧縮されたアーカイブファイルを回収するために、このドキュメントの原本は以下のPerlスクリプトに入力されるように通過されるかもしれません(出力は「-xzvfのタールを塗ってください」というファイルに向け直されるか、または運ばれて、ことであるべきです)。
Peterson & Jennings Standards Track [Page 34] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[34ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
if ( m/^\s*[^\s]+\s*$/) {
$bdata = $bdata . $_;
}
}
}
print decode_base64($bdata);
#/usr/bin/perl使用厳しい。 私の$bdataが等しい、「「;」 MIMEを使用してください:、:Base64。 while(<>) { if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { if ( m/^\s*[^\s]+\s*$/) { $bdata = $bdata . $_; } } } print decode_base64($bdata);
Alternatively, the base-64 encoded block can be edited by hand to remove document structure lines and fed as input to any base-64 decoding utility.
あるいはまた、どんなベース-64解読ユーティリティにも入力されるようにベース-64コード化されたブロックをドキュメント構造系列を取り除くために手で編集して、与えることができます。
B.1. Encoded Reference Files
B.1。 コード化された参照ファイル
-- BEGIN MESSAGE ARCHIVE -- H4sICFfaz0QCA25ld2lkZW50LnRhcgDsW0us5NhZ7gUSwqiF2CAhFikiIQhFt992 +U46it+u8qPK5Uc9WPlVfj/KdpXtomEDCxaAhFggISE2WSHCIoIFioQQC8gqAhRA QQTY8JJAbMgGIYTv7b7T09PT0xNl+mqS3F8qVd3jY/uc85//+87/nXOLoIv9oGjB B2/PIAiDSBwfv1GERInxG8EwAh6/37UHMIQRKIljCI4+gGCUGKtP8Ad3YKemderJ 5EFSBW1QN2Xxmnp5GtblqXqUPfIffBdZcet/p82conUee0H9sfsfhiACw17nfwQa y+Dra+MkQGFkrI+TOPJgAt37/63bo2tjeHGuTVh+bc6FOUub/E0poM7nLGqyLJ06 Id3NGTocPxytMWF6jNJYpDqIoXVLoDlmr+pNx+o7ztZ1ke8WtnXhFUClU5GGLZ6l O3YN8T3P0Usm1GyG9lQGEiBXFE6+yPecSSvPykuV4TPB5ne9xNEO8KxQVXnk3cqn /TaK3C3T7A08cRGokyJPUzmrV7k5pHK7i5bQyOambNcDLxUmH9zMD2sl8FGa+WGt BG6bGe5nHafvFnK5n0dnT6N1nmF0mgt3EK3OxQVdiuMzZrNOhPxNOF37W7w4LmsL OA0Mpeqt7RTKTrDX1CztZgezbM7rLlvQeBnhWzWOV5qDZEdMahLZTo8Wq0oZOL4X FgkgMhY4pNBdU53sHVvlaIX5TjqH0+JkYXAXmmzgSI7H9N3RvHingrIOAUIzCph4 GhsdHGDwET+WCO5SuDtwxXKNvneGYrWiQ5WhaTEJXb0LXb6Trgd2DS0ZZscLWm6B au3aO48HZK4GEWgzN2oRTuBaG/vLXA+aZKh8kDBYyJj7bHWREXgjMWxIgFQrxPyx b3eUc3EEH6iEptuYL1zFRCpr22rPXujFs9EPx0s+o67pbhzRa/eOjvEZX+wjt1hH gKpDHdvdXJA5er1Y22tRXXed+KwyxzFadFtZyW1st4E7V7ROO4Rqw5Cnx6ncXb/Z 5ztdUOmx34dX3Ck8cydPc76+a5uO4XLTMI9Q3iIwDJBOloNbUahd5OK7FnQu637t L/cQdlSHel5tRVjh84Jfhl7pDfV2zZyPeEVs3D3t8XoKAVzDo3YAad6sp4r8nCUb UmxUUWAL9lRiS848gHAm+nZNcQF78RIY2lk6qq6DnFO30Q4B2JaLG2WTkcZ2uVx7 ezqGS4vqngA30c5r3KsI8ODevsvtFf6v6vicBsMd8j+ME+Qt/0PjAnCsT5AQes// d8z/a4OerNZze4z+iczvXqwBtvrI+7TMhDq3WqlMK9nlKt3a0z2RHGGlCQ8jMtub akAY2zocFupKgghFgbyFoS8BZx7Yl3mZXDZt5ZwYcj5kezmjEwY/YCO4rk+lFQc+ 26mK7GYb+rhviUDaVKy2X5DZUvOAOd8VeYQUtOfJ6QxVKtCW0DakDRBDOb3cIk3h F7toGs5wBFldupDkxU1TXS7dnKN1mgFumFWGNmhb8AJH0omt08VC23Jtj1O0A9sn ZMFvA6KMp8s6FYZmkbj7RdcoudzWYdsCq+3SmrVIvq9iqJOxaIu1+6ho406UU2vF ohHFJNVUDOr4sEIxeK0O6nJKHFZhclxeLK4DpvUqSdSqG1+eerx35ELXrPfF5gzq BWs4joD2qSUehFTp8aXsremUp0mrLxp+tnVMFALaFWhZHg6HWorIohz2um5KZcV4 QUcNh4BdC9HZV8ikckSn5WM83neiONKavbQlS4MlANoplaQn67JbMLQ2XSPumQa1
-- メッセージアーカイブを始めてください; 5EFSBW1QN2Xxmnp5GtblqXqUPfIffBdZcet/p82conUee0H9sfsfhiACw17nfwQa y+Dra+MkQGFkrI+TOPJgAt37/63bo2tjeHGuTVh+bc6FOUub/E0poM7nLGqyLJ06 Id3NGTocPxytMWF6jNJYpDqIoXVLoDlmr+pNx+o7ztZ1ke8WtnXhFUClU5GGLZ6l O3YN8T3P0Usm1GyG9lQGEiBXFE6+yPecSSvPykuV4TPB5ne9xNEO8KxQVXnk3cqn; /TaK3C3T7A08cRGokyJPUzmrV7k5pHK7i5bQyOambNcDLxUmH9zMD2sl8FGa+WGt BG6bGe5nHafvFnK5n0dnT6N1nmF0mgt3EK3OxQVdiuMzZrNOhPxNOF37W7w4LmsL OA0Mpeqt7RTKTrDX1CztZgezbM7rLlvQeBnhWzWOV5qDZEdMahLZTo8Wq0oZOL4X FgkgMhY4pNBdU53sHVvlaIX5TjqH0+JkYXAXmmzgSI7H9N3RvHingrIOAUIzCph4 GhsdHGDwET+WCO5SuDtwxXKNvneGYrWiQ5WhaTEJXb0LXb6Trgd2DS0ZZscLWm6B au3aO48HZK4GEWgzN2oRTuBaG/vLXA+aZKh8kDBYyJj7bHWREXgjMWxIgFQrxPyx b3eUc3EEH6iEptuYL1zFRCpr22rPXujFs9EPx0s+o67pbhzRa/eOjvEZX+wjt1hH gKpDHdvdXJA5er1Y22t26mK7GYb+rhviUDaVKy2X5DZUvOAOd8VeYQUtOfJ6QxVKtCW0DakDRBDOb3cIk3h F7toGs5wBFldupDkxU1TXS7dnKN1mgFumFWGNmhb8AJH0omt08VC23Jtj1O0A9sn ZMFvA6KMp8s6FYZmkbj7RdcoudzWYdsCq+3SmrVIvq9iqJOxaIu1+6ho406UU2vF ohHFJNVUDOr4sEIxeK0O6nJKHFZhclxeLK4DpvUqSdSqG1+eerx35ELXrPfF5gzq BWs4joD2qSUehFTp8aXsremUp0mrLxp+tnVMFALaFWhZHg6HWorIohz2um5KZcV4 QUcNh4BdC9HZV8ikckSn5WM83neiONKavbQlS4MlANoplaQn67JbMLQ2XSPumQa1
Peterson & Jennings Standards Track [Page 35] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[35ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
OD9iBLYPiyDjudXR4en9xuHQdHmIDGp6VsjyyBvTE85DwIJMty65T2PDtkJqa4Gz Va/KPcjRF8i38qUytVhdmrEUb1rqHDnx7lFyGd+2RC1FCYwFOMErfKO3oymKyceF n8Q7oyfs1eqMEFsqJw1oOfhmaoQNCmJluerLmeSox20+g1idmdZA7zKolVXLMvKY TpCp3KwzlSHYhjpmBCGHXZEp1CnlI0nalZdxHPxtUDLsEFlNGfqGBRCgY9CCd97w YpuQ4HlY8Kyus6wBZ3LIb0tNXx2XmpOdd9EwqPv1VlB8Dgvdbr2S4dNWBnZVirLp Qbgsh0MSKJ646reXI3K8nKSLaHL9nlrRQdVtsbWRviDVDwyrTzD+n9yPGf7fhP8j 5kO3+I/AN/k/gZHYPf7fMf6vLEaZs++FfvGg0pDIGkfRmLsj2PLX6R5NY6JGcywT 6x9OCcDrOOGjUgLwOk74qJQAvJYT3o3O93f6e3b958ZZ2cdvQ/55s/6DvEf/QbBr /YeAifv4/yToP3DCsnQyfZP+s32j/mOO6Tp3ub75uf6TLipXpDDH5DWVbp7VCzve sGxrnfDuWEEErgvprjN2eda4aFS9PzVXGWzLmTSsmvSgcTQyfgYtK6/LkOsy4D2F nX15k4AAm6p+k9Y/FxD2LOBs+nMgph+o/YgXev+u9pM/746BZ4EotJ7YZ0qunQHX ZJni8v5B4wWaXjKJTnfhLmWvRYMzIXYbFjI5jFzInZwlZZR0gmoAGoi39e6ENYEk HsO0UyJ7umXRkl/i+LGOLxE6zD3bkFOqoJYZrS3Mo5bYjjSc16cLjwvABjZ3Tbgw EIHu51MYjruBLihkPUwjBwTDKJjJ0MqZLpQpjMVG40i2HhaHDtNTcH08ZDpASGdm Vh2T7DzUC/SINbE6epSnaWfJNGP36oT2b+QcHeOFULeg/XStYOQGpFdc6+EMcDBK fXviBR7sukN3IxIljBR2fkm/UvlF3SHaEOu9Kng98MJNO5PObPM9s20E9IU2zrbV NVXduLbrRP35fLmVfYCXdZ9mrHGr+yzi5y5+n7CIsCNRdBx901oTYGirG/vMgJcP mP/XeqHOxIMszduZuT2I2qEqFtsYT9j4suzz3WwHhFkxa4eV4ATDkcJN0Tub7Obi l4xiVww3PVTrTb0F53O84Qlbcl16TBnsXHb33UWn26oCVojgnBJk1lLYPuAkDTkf L8mhkBJ2iWCpiC5OB8ScQXFWUTvJ47o+sYS6nRFWkbHTIfaBwTGDU7PBxRN5hsMn 97rPvb3K/29B/nmz/kOit/wPI+NaYFz/49j9/s8nR/8Jb/UfFixdZqes1VXSpDV9 3CxjcUVb/RwFc6SNybjHPOfImvRJ2OKeEoQ6QBb58aQspcM86u350UQOEGHRULYs Ec0uDzIlkqqZ2q6txQOdKTuL4xNyu1G4OXtA95ICEEINTlmB7GqdqrH0TG7jhdyX vs2yPshFrEmJ1dTmymAmDflxuQHlpgjqeJi/pP8syEMjzOWtnCabMJmljbhsIwM1 CpjqVwY78D7TH/gcWSUkqF0uQRaDK2/pxB6UAouR+r3iqCEHiQ/mogxSvcX05ukQ 6jt7cTwPEr9uiHq7BWMT2xU51cIUhPOxTu0rqannADguEKwdDeu1GNJz6bxXbOVy nFKywvH7qaS7J1ZZbIUp4WYQ7+LMtf5DoESp0loF6Q4K5LsNryOnNhebXZ9ujcPA uPDMZJcd2w5Q4TNrBLsMy4WAaO7eoGbKZSo6CB4d5mIHLiQZKDjKXfKzmXWj/zBr o/IxNzemOTZbgzDarnmDbqXj4GtxsYVSA1xHnVSTeSqZFpqCKiD0etuj2BwV5Yuz 79UCoglCNqgzaEh+IUyD1Y2YIgak3kTDfnaKW2XV7jkvYzcRL0vAkdal3OL3Z0tA bEmp3VOqKMtQsmpJcxDMmytnzEcHh7WtoB1yzTsNZhfJCYJ1Ap3SS+ACJj3MV5mG Rp0y1Zos25ebOT47nU8kSB8RD/UuR8cWGddFYbKR2F0op5BLi2jaLdE8BigUVLYb E/b8eGdXOeNJ3M1I51WYCsm035/wcEMbO/yUnKcCq66gTedIeGQW29O0lQNgtUB9 ZL7Yy71YZETcymuNFIN1RK0MGUr3Y5osBHZ9bhaYVlYvEewnVwN6Bf8/fvnnW9N/ yBv9B8Wge/z/jtB/Xk8JwOs44aNSAvA6TviolAC8lhPu9Z9X4n8IHntOURax52R3 G//jAvD5+S8MxbGb9R8K38f/nVgTV1du6X7+OfwHvZNXWfC4rMOn15ecLPaCz9/u Ddxe9cr8qTPDXMwjiYAgRtx+iqDwhNnxT83o9DMTBJ4IgTtBRkdPYOwKpq5weCKq 5tOn9wnXJzn+b37F7cdM/2/M/2AUe3H+E7vZ/0eg+/2fO7ExZicvAr3yUPTxB0T7 xJivQOQx9BCwY+fq9i/QVIwJTI2/HiOPsXfc2im86MmFikTMlQunifwGHm9Rnf6R UNadU/vN1YQcS4S6zK8mTOlOPvt6/PncO60TPnEIb4Z7h4eAWV5N6OtGPrvntcD0 7LaxVTMUgkkSewhwThtcTT4UmB4CrJNlj+bc1eRlXBsvGMHxavIc3h4C8+chcjX5 dHPGWbOEcPlYGXkrtajv8fEShNmNaezbQkRjewoX+alWtjYo5e2gGaTS1iHlZ326 uZQPgckLCyzSJ5f2TOoC0+RK10bj1szDVccKicPn6sDPUZ80Bg2BB40rEX4NLs9h 20HKCfeaefXSw6rVcRnCp23hXyRXJPM1sc4oprAi6XSw126Fw2qBdlB4sJonn37R p0fz4jCO8mejtq2aKxB81Sfv2SX63DtOFj6pG+dREznwOE5l0Y6PeaQERdhGV5Nx 6O7R9TsM//OgaZwwuOP9Pwh7cf57hH7i5vw3gd/j/z3+fyz4/1Gh/XsSwV6K/2sk fwvveFP8QyRxm/9hY43r+Efg+/Ofd2KGRMM/9VLu/5knkwM5IyjUP6A4jPuI5wfU GEw4jsEocX2ghnQdGMbgA3bP8N9l8R+HReDfefwj7/7/H0ZCOPHs/A95H/93YV/6
+ + YpuQ4HlY8Kyus6wBZ3LIb0tNXx2XmpOdd9EwqPv1VlB8Dgvdbr2S4dNWBnZVirLp Qbgsh0MSKJ646reXI3K8nKSLaHL9nlrRQdVtsbWRviDVDwyrTzD+n9yPGf7fhP8j 5kO3+I/は/k/gZHYPf7fMf6vLEaZs FfvGg0pDIGkfRmLsj2PLX6R5NY6JGcywT55 6x9OCcDrOOGjUgLwOk74qJQAvJYT3o3O93f6e3b958ZZ2cdvQ/年代/6DvEf/QbBrです; 5PObPM9s20E9IU2zrbV NVXduLbrRP35fLmVfYCXdZ9mrHGr+yzi5y5+n7CIsCNRdBx901oTYGirG/vMgJcP mp/XeqHOxIMszduZuT2I2qEqFtsYT9j4suzz3WwHhFkxa4eV4ATDkcJN0Tub7Obi l4xiVww3PVTrTb0F53O84Qlbcl16TBnsXHb33UWn26oCVojgnBJk1lLYPuAkDTkf L8mhkBJ2iWCpiC5OB8ScQXFWUTvJ47o+sYS6nRFWkbHTIfaBwTGDU7PBxRN5hsMn; 97rPvb3K/29B/nmz/kOit/wPI+NaYFz/49j9/s8nR/8Jb/UfFixdZqes1VXSpDV9 3CxjcUVb/RwFc6SNybjHPOfImvRJ2OKeEoQ6QBb58aQspcM86u350UQOEGHRULYs Ec0uDzIlkqqZ2q6txQOdKTuL4xNyu1G4OXtA95ICEEINTlmB7GqdqrH0TG7jhdyX vs2yPshFrEmJ1dTmymAmDflxuQHlpgjqeJi/pP8syEMjzOWtnCabMJmljbhsIwM1; CpjqVwY78D第7/gcWSUkqF0uQRaDK2/pxB6UAouR+r3iqCEHiQ/mogxSvcX05ukQ6jt7cTwPEr9uiHq7BWMT2xU51cIUhPOxTu0rqannADguEKwdDeu1GNJz6bxXbOVy nFKywvH7qaS7J1ZZbIUp4WYQ7+LMtf5DoESp0loF6Q4K5LsNryOnNhebXZ9ujcPA uPDMZJcd2w5Q4TNrBLsMy4WAaO7eoGbKZSo6CB4d5mIHLiQZKDjKXfKzmXWj/zBr o/IxNzemOTZbgzDarnmDbqXj4GtxsYVSA1xHnVSTeSqZFpqCKiD0etuj2BwV5Yuz79UCoglCNqgzaEh+IUyD1Y2YIgak3kTDfnaKW2XV7jkvYzcRL0vAkdal3OL3Z0tA bEmp3VOqKMtQsmpJcxDMmytnzEcHh7WtoB1yzTsNZhfJCYJ1Ap3SS+ACJj3MV5mG Rp0y1Zos25ebOT47nU8kSB8RD/UuR8cWGddFYbKR2F0op5BLi2jaLdE8BigUVLYb1RK0MGUr3Y5osBHZ9bhaYVlYvEewnVwN6Bf8/fvnnW9N/yBv9B8Wge/z/jtB/Xk8JwOs44aNSAvA6TviolAC8lhPu9Z9X4n8IHntOURax52R3 G//jAvD5+S8MxbGb9R8K38f/nVgTV1du6X7+OfwHvZNXWfC4rMOn15ecLPaCz9/u Ddxe9cr8qTPDXMwjiYAgRtx+iqDwhNnxT83o9DMTBJ4IgTtBRkdPYOwKpq5weCKq 5tOn9wnXJzn+b37F7cdM/2/M/2AUe3H E/b8eGdXOeNJ3M1I51WYCsm035/wcEMbO/yUnKcCq66gTedIeGQW29O0lQNgtUB9 ZL7Yy71YZETcymuNFIN+E7vZ/0eg+/2fO7ExZicvAr3yUPTxB0T7 xJivQOQx9BCwY+fq9i/QVIwJTI2/HiOPsXfc2im86MmFikTMlQunifwGHm9Rnf6R; UNadU/vN1YQcS4S6zK8mTOlOPvt6/PncO60TPnEIb4Z7h4eAWV5N6OtGPrvntcD0 7LaxVTMUgkkSewhwThtcTT4UmB4CrJNlj+bc1eRlXBsvGMHxavIc3h4C8+chcjX5 dHPGWbOEcPlYGXkrtajv8fEShNmNaezbQkRjewoX+alWtjYo5e2gGaTS1iHlZ326 uZQPgckLCyzSJ5f2TOoC0+RK10bj1szDVccKicPn6sDPUZ80Bg2BB40rEX4NLs9h; 20HKCfeaefXSw6rVcRnCp23hXyRXJPM1sc4oprAi6XSw126Fw2qBdlB4sJonn37R p0fz4jCO8mejtq2aKxB81Sfv2SX63DtOFj6pG+dREznwOE5l0Y6PeaQERdhGV5Nx 6O7R9TsM//OgaZwwuOP9Pwh7cf57hH7i5vw3gd/j/z3+fyz4/1Gh/XsSwV6K/2sk fwvveFP8QyRxm/9hY43r+Efg+/Ofd2KGRMM/9VLu/5knkwM5IyjUP6A4jPuI5wfU GEw4jsEocX2ghnQdGMbgA3bP8N9l8R+HReDfefwj7/7/H0ZCOPHs/A95H/93YV/6
Peterson & Jennings Standards Track [Page 36] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[36ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
P0b7Veqnf3f9W3/5n9/42+/75f/65g/4f3X4+p/9w0/8wt8Mv/97f/jX/zt88Stf +/Ljv/unb379+OvZvw3aN/7jn59+6vt/Q7n6sU3/RS36oT/5cS+a/8pXGLL7gy+R eY1dET/8qa/+8Q9Wf/HlP6r/9DNf+J9f+8Wf/c3f/vs/z4p/Eb8Q/PePfu2Xfu53 rB/59381fvIfH05+Xr6PwE9c/D8OCu9u4/+F/nt9BOBG/yXuz//djf77bYoYwLcr XADfilhxv+B4a/EfF+e4fTtbQG+Kfxy6Pv+D4SiMosTN+V9yzAnu4/9O4v9DN3k+ ZHfoffs/6JgQ4NRkrtlz84N2gdArCLmC0JtdoDfrDU/PT8bsu3xiNUFN/3875/Pa NBiH8Yt6CBS0Q2SDYcYEkSl9k75Nmkmn7ebWde2WLm3646Jp2q7FtU2btq496EGc KMgu4sH5a4dN8NccCMLYP6AMwcv+Bg/e1NMuZimTdlvXyWxx4/s5pQ0N5SXPk/d9 nrclaSuHrBhbaKb6cHiUHOYxWe8SBkK1CTFVTWbSpDDAGwjZ1vATeRvaWPWnbFIh msyQmKNYmhz38Sa7yG+ckGy5vJKSlF5E8v0ev8mq3bwHPCTYqv9mVEAN9//p+Z+m f9qCMMvqv/+k4fnfEiqCJbcJfVPnuyR/9XS0YxBorSR4jTK/zWywKUlfjUftlEvW a4qqzKsSE0pyvrf629Ubir6awigcGnVEnP0IiZ5wjr4ezjNiqr/IZ9IBl2eo6PU5 BrITiUwg5p5yxcsOWqKUKXvOLE7kHEhQBbtU0/Ek4+p4NDnGZ7zh0FiJvpETJxKF hKx6Is6AXxicGmYUJmvxjXmDTk+qzBSuZMxq0aUKTszlE6WhdM3FBkU5XZLCPT2l 8UlHKOT1ubOBsqtnREzwI5G436TkSgkxzYVkxr9bYbTDCFT/r0y9yshXUrRhlxRF G0sprxm2SY0q2/NYCrMGwkDAo6GZ/t+MCqhh/4/MVf2Pvv7DDMz/wP8Pg/+DyQEH yP+bUQE23P+JqD/zfxpZ9P5fewv8vwXo/d/W7OecjaRZhGWaZq04LtGUjCPIwkUQ krUXmI1xEstIUQmbOVD/IdN/EyrAPfZ/Ff2z+v5P7RD03wpit+2TyoevQvtisv3j fJz48e1pxN3xs+1I74vpO89MxqurnY/XnlxeLFx702lcIjvurZ8ods/MHQtevPD+ bbBr+dR5amnN25XtflV+/fCLPbs62/fO+OD7yqzx9EzqbtfLk4GznxZurp+JHZ0+ 7l5+tPr8vtj2OfXr0sLKnHgrqM6DAv9H/f/bCnCP/Z+ufzOm9PyfhfVfS9hvJkXs N4ci/iZ7gtkGAAAAAAAAAAAAAAAAAAAAAAAAAABAPX4DY+BfEQB4AAA= -- END MESSAGE ARCHIVE --
+ P0b7Veqnf3f9W3/5n9/42+/75f/65g/4f3X4+p/9w0/8wt8Mv/97f/jX/zt88Stf+/Ljv/unb379+OvZvw3aN/7jn59+6vt/Q7n6sU3/RS36oT/5cSは/z4p/Eb8Q/PePfu2Xfu53 rB/59381fvIfH05+Xr6PwE9c/D8OCu9u4/+F/nt9BOBG/yXuz//djf77bYoYwLcrに対する/8pXGLL7gy+R eY1dET/8qa/+8Q9Wf/HlP6r/9DNf+J9f+8Wf/c3f/です; XADfilhxv+B4a/効率+e4fTtbQG+Kfxy6Pv+D4SiMosTN+V9yzAnu4/9O4v9DN3k+ZHfoffs/6JgQ4NRkrtlz84N2gdArCLmC0JtdoDfrDU/PT8bsu3xiNUFN/3875/Pa NBiH8Yt6CBS0Q2SDYcYEkSl9k75Nmkmn7ebWde2WLm3646Jp2q7FtU2btq496EGc KMgu4sH5a4dN8NccCMLYP6AMwcv+Bg/e1NMuZimTdlvXyWxx4/s5pQ0N5SXPk/d9; nrclaSuHrBhbaKb6cHiUHOYxWe8SBkK1CTFVTWbSpDDAGwjZ1vATeRvaWPWnbFIh msyQmKNYmhz38Sa7yG+ckGy5vJKSlF5E8v0ev8mq3bwHPCTYqv9mVEAN9//p+Z+m f9qCMMvqv/+k4fnfEiqCJbcJfVPnuyR/9XS0YxBorSR4jTK/zWywKUlfjUftlEvW a4qqzKsSE0pyvrf629Ubir6awigcGnVEnP0IiZ5wjr4ezjNiqr/IZ9IBl2eo6PU5 BrITiUwg5p5yxcsOWqKUKXvOLE7kHEhQBbtU0/Ek4+p4NDnGZ7zh0FiJvpETJxKF hKx6Is6AXxicGmYUJmvxjXmDTk+qzBSuZMxq0aUKTszlE6WhdM3FBkU5XZLCPT2l8UlHKOT1ubOBsqtnREzwI5G436TkSgkxzYVkxr9bYbTDCFT/r0y9yshXUrRhlxRF G0sprxm2SY0q2/NYCrMGwkDAo6GZ/t+MCqhh/4/MVf2Pvv7DDMz/wP8Pg/+DyQEH yP+bUQE23P+JqD/zfxpZ9P5fewv8vwXo/d/W7OecjaRZhGWaZq04LtGUjCPIwkUQ krUXmI1xEstIUQmbOVD/IdN/EyrAPfZ/Ff2z+v5P7RD03wpit+2TyoevQvtisv3j fJz48e1pxN3xs+1I74vpO89MxqurnY/XnlxeLFx702lcIjvurZ8ods/MHQtevPD+bbBr+dR5amnN25XtflV+/fCLPbs62/fO+OD7yqzx9EzqbtfLk4GznxZurp+JHZ0+7l5+tPr8vtj2OfXr0sLKnHgrqM6DAv9H/f/bCnCP/Z+ufzOm9PyfhfVfS9hvJkXs N4ci/iZ7gtkGAAAAAAAAAAAAAAAAAAAAAAAAAABAPX4DY+BfEQB4AAA=--メッセージアーカイブを終わらせてください--
Peterson & Jennings Standards Track [Page 37] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[37ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
Appendix C. Original Requirements
付録のC.のオリジナルの要件
The following requirements were crafted throughout the development of the mechanism described in this document. They are preserved here for historical reasons.
以下の要件は本書では説明されたメカニズムの開発の間中作られました。 それらは歴史的な理由でここに保存されます。
o The mechanism must allow a UAC or a proxy server to provide a
strong cryptographic identity assurance in a request that can be
verified by a proxy server or UAS.
o User agents that receive identity assurances must be able to
validate these assurances without performing any network lookup.
o User agents that hold certificates on behalf of their user must be
capable of adding this identity assurance to requests.
o Proxy servers that hold certificates on behalf of their domain
must be capable of adding this identity assurance to requests; a
UAC is not required to support this mechanism in order for an
identity assurance to be added to a request in this fashion.
o The mechanism must prevent replay of the identity assurance by an
attacker.
o In order to provide full replay protection, the mechanism must be
capable of protecting the integrity of SIP message bodies (to
ensure that media offers and answers are linked to the signaling
identity).
o It must be possible for a user to have multiple AoRs (i.e.,
accounts or aliases) that it is authorized to use within a
domain, and for the UAC to assert one identity while
authenticating itself as another, related, identity, as permitted
by the local policy of the domain.
o UACかプロキシサーバがメカニズムでプロキシサーバかUASが確かめることができる要求における強い暗号のアイデンティティ保証を提供できなければなりません。どんなネットワークルックアップも実行しないで、アイデンティティ保証を受け取るo Userエージェントはこれらの保証を有効にすることができなければなりません; 彼らのユーザを代表して証明書を保持するo Userエージェントはこのアイデンティティ保証を要求に追加できなければなりません。それらのドメインを代表して証明書を保持するo Proxyサーバはこのアイデンティティ保証を要求に追加できなければなりません。 UACは、こんなやり方で要求に追加されるためにアイデンティティ保証で整然としているこのメカニズムをサポートするのに必要ではありません。○ メカニズムは攻撃者によるアイデンティティ保証の再生を防がなければなりません。完全な反復操作による保護を提供するo In命令、メカニズムはSIPメッセージボディー(メディア申し出と答えがシグナリングのアイデンティティにリンクされるのを保証する)の保全を保護できなければなりません; 別のものとしてそれ自体を認証している間、ユーザがそれがドメインの中で使用するのが認可される複数のAoRs(すなわち、アカウントか別名)を持って、UACが1つのアイデンティティについて断言するのにおいてo Itは可能であるに違いありません、関連しています、アイデンティティ、ドメインのローカルの方針で受入れられるように。
Peterson & Jennings Standards Track [Page 38] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[38ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
References
参照
Normative References
引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[3] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[5] ピーターソン、J.、「セッション開始プロトコル(一口)はアイデンティティ本体(AIB)形式を認証した」RFC3893、2004年9月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[6] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, August 2002.
[7]Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[8]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[9] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[9]Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[10] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", RFC 2585,
May 1999.
[10]Housley、R.、およびP.ホフマン、「インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル:」 「FTPとHTTP」(RFC2585)は1999がそうするかもしれません。
[11] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[11] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
Informative References
有益な参照
[12] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[12] ジョニングス、C.、ピーターソン、J.、およびM.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
[13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[13]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
Peterson & Jennings Standards Track [Page 39] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[39ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
[14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[14]FaltstromとP.とM.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。
[15] Peterson, J., "Retargeting and Security in SIP: A Framework and
Requirements", Work in Progress, February 2005.
[15] ピーターソン、J.、「Retargetingとセキュリティは中でちびちび飲みます」。 「枠組みと要件」は進歩、2005年2月に働いています。
[16] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture
Test Messages, RFC 4475, May 2006.
[16]スパーク、R.Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始プロトコル(一口)耐久テストメッセージ、RFC4475、2006年5月」(エド)。
Authors' Addresses
作者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA
カレンジョニングスシスコシステムズ170の西タスマンDrive MS: SJC-21/2カリフォルニア95134サンノゼ(米国)
Phone: +1 408 902-3341 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 408 902-3341 メールしてください: fluffy@cisco.com
Peterson & Jennings Standards Track [Page 40] RFC 4474 SIP Identity August 2006
ピーターソンとジョニングス標準化過程[40ページ]RFC4474はアイデンティティ2006年8月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Peterson & Jennings Standards Track [Page 41]
ピーターソンとジョニングス標準化過程[41ページ]
一覧
スポンサーリンク
