[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Issue 153: Generalized Interactive Challenge for WS-Trust
Marc, Is this a proposal for an extension of the WS-Trust 1.3 standard? As in a new version of WS-Trust? Thanks, prateek > > Issue 153 > > *From:* Marc Goodner [mailto:mgoodner@microsoft.com] > *Sent:* Tuesday, November 13, 2007 4:16 PM > *To:* ws-sx@lists.oasis-open.org > *Subject:* [ws-sx] New Issue: Generalized Interactive Challenge for > WS-Trust > > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. > The issues coordinators will notify the list when that has occurred. > > Title: Generalized Interactive Challenge for WS-Trust > Protocol: Trust > Artifact: spec > Type: design > > Description: > > The security token services (STS) framework defined by WS-Trust allows > for a simple request and response for security tokens as well as an > extension mechanism to enable exchanges for negotiation and > challenges. The WS-Trust specification defines a “signature challenge” > construct as a specific type of exchange that makes use of the above > extension mechanism for general exchanges. > > There are many scenarios where an STS may require further interactions > with the requestor prior to returning a security token, beyond the > authentication requirements expressed in its security policy and > satisfied by the security tokens bound to the initial RST request > through SOAP security header. Following are examples of exchanges > where an STS may further challenge the requestor for additional > interactive input, to supplement authentication information submitted > in the original request in the SOAP security header, before issuing > the requested token. > > · Prompt the user for an additional shared secret such as a PIN. > > · Prompt the user for second-factor authentication data such as “one > time password” (OTP) taken from an OTP device or module. > > · Prompt the user for answers to text-based secret questions (e.g., > mother’s maiden name, date of birth) as either text inputs or > multiple-choice inputs. > > · Prompt the user for answers to image-based challenges as either text > inputs or multiple-choice inputs. > > The challenge may be selectively issued by the STS only for particular > users or for token requests for particular target scopes. The specific > user or target scope can only be identified after the initial request > is received. > > In all such cases, however, the supplemental authentication > information required by the STS does not cause a reset of the security > policy of the STS. Specifically, the additional information requested > by the STS in the form of challenge and response exchanges is carried > entirely within the RST/RSTR message bodies and does not affect the > authentication information carried inside the SOAP security headers in > any way. The security token content in the SOAP security headers > remains unchanged across the user interaction challenge/response > exchanges. > > This proposal defines a “user interaction challenge” construct, as a > strongly typed mechanism, for issuing interactive challenges and > receiving corresponding responses within the WS-Trust framework inside > the bodies of RST/RSTR messages. The proposed mechanism easily fits > into the general exchanges mechanism already defined in WS-Trust. > > Proposal: > > Add the following section to section 8, Negotiation and Challenge > Extensions after section 8.2. Existing sections 8.3 through 8.6 > increment accordingly. To be consistent with the existing section the > examples for interactive challenges should be added as section 8.8 > after the existing section 8.6 (renumbered to 8.7) on signature > challenge examples. Remaining existing sections 8.7 through 8.9 > increment accordingly. > > Also, add a new property to SecurityPolicy 1.3 in the Trust 1.3 > assertion and a new nested assertion to control the setting of that > property. > > All new elements, attributes, URIs are to be defined under the Trust > 1.4 namespace, represented here with the wst14 namespace prefix and > the placeholder URI http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm. > New assertions for SecurityPolicy 1.3 are defined under sp13 namespace > prefix and the placeholder URI > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/yyyymm. > > WS-SecurityPolicy change for Trust 1.3 assertion > > [Interactive Challenge] > > This boolean property indicates whether interactive challenges are > supported. A value of 'true' indicates that a > wst14:InteractiveChallenge element is supported inside of an RSTR sent > by the server to the client. A value of 'false' indicates that > wst14:InteractiveChallenge is not supported. A challenge issued by the > server may increase the number of messages exchanged by the client and > service in order to accommodate the wst14:InteractiveChallengeResponse > element sent by the client to the server in response to the > wst14:InteractiveChallenge element. There is an optimization in which > a client MAY send the wst14:InteractiveChallengeResponse element in an > initial RST to the server. A final RSTR containing the issued token > will follow subsequent to the server receiving the > wst14:InteractiveChallengeResponse element. This property has a > default value of 'false'. > > /sp:Trust13/wsp:Policy/sp13:MustSupportInteractiveChallenge > > This optional element is a policy assertion indicates that the > [Interactive Challenge] property is set to 'true'. > > > 8.3 User Interaction Challenge > > User interaction challenge requests are issued by including the > <InteractiveChallenge> element. The response is returned in a > <InteractiveChallengeResponse> element. Both the challenge and > response elements are specified within the > <wst:RequestSecurityTokenResponse> element. In some instances, the > requestor may issue a challenge to the recipient or provide a response > to an anticipated challenge from the recipient in the initial request. > Consequently, these elements are also allowed within a > <wst:RequestSecurityToken> element. The challenge/response exchange > between client and server MAY be iterated over multiple legs before a > final response is issued. Note that the xml:lang attribute may be used > where allowed via attribute extensibility to specify a language of > localized elements and attributes using the language codes specified > in [RFC 3066]. > > > 8.3.1 Challenge Format > > The syntax of the user interaction challenge element is as follows: > > <wst14:InteractiveChallenge xmlns:wst14="..." ...> > > <wst14:Title ...> /xs:string /</wst14:Title> ? > > <wst14:TextChallenge RefId="/xs:anyURI/" Label=/"xs:string"/? > MaxLen="/xs:int/"? HideText="/xs:boolean/"? ...> > > <wst14:Image MimeType="/xs:string/"> /xs:base64Binary/ </wst14:Image> ? > > </wst14:TextChallenge> * > > <wst14:ChoiceChallenge RefId="/xs:anyURI/" Label="/xs:string/"? > ExactlyOne="/xs:boolean/"? ...> > > <wst14:Choice RefId="/xs:anyURI/" Label=/"xs:string"/? ...> > > <wst14:Image MimeType="/xs:string/"> /xs:base64Binary/ </wst14:Image> ? > > </wst14:Choice> + > > </wst14:ChoiceChallenge> * > > < wst14:ContextData RefId="/xs:anyURI/"> /xs:any /</wst14:ContextData> * > > ... > > </wst14:InteractiveChallenge> > > The following describes the attributes and elements listed in the > schema outlined above: > > .../wst14:InteractiveChallenge > > A container element for a challenge that requires interactive user input. > > .../wst14:InteractiveChallenge/wst14:Title > > An optional element that specifies an overall title text to be > displayed to the user (e.g. a title describing the purpose or nature > of the challenge). How the preferred language of the requestor is > communicated to the STS is left up to implementations. > > .../wst14:InteractiveChallenge/wst14:TextChallenge > > An optional element that specifies a challenge that requires textual > input from the user. > > .../wst14:InteractiveChallenge/wst14:TextChallenge/@RefId > > A required attribute that specifies a reference identifier for this > challenge element which is used to correlate the corresponding element > in the response to the challenge. > > .../wst14:InteractiveChallenge/wst14:TextChallenge/@MaxLen > > An optional attribute that specifies the maximum length of the text > string that is sent as the response to this text challenge. This value > serves as a hint for the user interface software at the requestor > which manifests the end-user experience for this challenge. > > .../wst14:InteractiveChallenge/wst14:TextChallenge/@HideText > > An optional attribute that specifies that the response to this text > challenge MUST receive treatment as hidden text in any user interface. > For example, the text entry may be displayed as a series of asterisks > in the user interface. This attribute serves as a hint for the user > interface software at the requestor which manifests the end-user > experience for this challenge. > > .../wst14:InteractiveChallenge/wst14:TextChallenge/@Label > > An optional attribute that specifies a label for the text challenge > item (e.g. a label for a text entry field) which will be shown to the > user. How the preferred language of the requestor is communicated to > the STS is left up to implementations. > > .../wst14:InteractiveChallenge/wst14:TextChallenge/Image > > An optional element that contains a base64 encoded inline image > specific to the text challenge item to be shown to the user (e.g. an > image that the user must see to respond successfully to the challenge). > > .../wst14:InteractiveChallenge/wst14:TextChallenge/Image/@MimeType > > A required attribute that specifies a MIME type (e.g., image/gif, > image/jpg) indicating the format of the image. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge > > An optional element that specifies a challenge that requires a choice > among multiple items by the user. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@RefId > > A required attribute that specifies a reference identifier for this > challenge element which is used to correlate the corresponding element > in the response to the challenge. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@Label > > An optional attribute that specifies a title label for the choice > challenge item (e.g., a text header describing the list of choices as > a whole) which will be shown to the user. How the preferred language > of the requestor is communicated to the STS is left up to implementations. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@ExactlyOne > > An optional attribute that specifies if exactly once choice must be > selected by the user from among the child element choices. The absence > of this attribute implies the value “false” which means multiple > choices can be selected. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice > > A required element that specifies a single choice item within the > choice challenge. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@RefId > > A required attribute that specifies a reference identifier for this > specific choice item which is used to correlate the corresponding > element in the response to the challenge. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@Label > > An optional attribute that specifies a text label for the choice item > (e.g., text describing the individual choice) which will be shown to > the user. How the preferred language of the requestor is communicated > to the STS is left up to implementations. > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image > > An optional element that contains a base64 encoded inline image > specific to the choice item to be shown to the user (e.g. an image > that the user must see to respond successfully to the challenge). > > .../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image/@MimeType > > A required attribute that specifies a MIME type (e.g., image/gif, > image/jpg) indicating the format of the image. > > .../wst14:InteractiveChallenge/wst14:ContextData > > An optional element that specifies a value that MUST be reflected back > in the response to the challenge (e.g., cookie). The element may > contain any value. The actual content is opaque to the requestor; it > is not required to understand its structure or semantics. This can be > used by an STS, for instance, to store information between the > challenge/response exchanges that would otherwise be lost if the STS > were to remain stateless. > > .../wst14:InteractiveChallenge/wst14:ContextData/@RefId > > A required attribute that specifies a reference identifier for this > context element which is used to correlate the corresponding element > in the response to the challenge. > > .../wst14:InteractiveChallenge/{any} > > This is an extensibility mechanism to allow additional elements to be > specified. > > .../wst14:InteractiveChallenge/@{any} > > This is an extensibility mechanism to allow additional attributes to > be specified. > > The syntax of the user interaction challenge response element is as > follows: > > <wst14:InteractiveChallengeResponse xmlns:wst14="..." ...> > > <wst14:TextChallengeResponse RefId="/xs:anyURI/" ...> > > /xs:string/ > > / /</wst14:TextChallengeResponse> * > > <wst14:ChoiceChallengeResponse RefId="/xs:anyURI/"> * > > <wst14:ChoiceSelected RefId="/xs:anyURI/" /> * > > </wst14:ChoiceChallengeResponse> > > <wst14:ContextData RefId="/xs:anyURI/"> /xs:any /</wst14:ContextData> * > > ... > > </wst14:InteractiveChallengeResponse> > > The following describes the attributes and elements listed in the > schema outlined above: > > .../wst14:InteractiveChallengeResponse > > A container element for the response to a challenge that requires > interactive user input. > > .../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse > > This element value contains the user input as the response to the > original text challenge issued. > > .../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse/@RefId > > A required attribute that specifies the identifier for the text > challenge element in the original challenge which can be used for > correlation. > > .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse > > A container element for the response to a choice challenge. > > .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/@RefId > > A required attribute that specifies the reference identifier for the > choice challenge element in the original challenge which can be used > for correlation. > > .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected > > A required element that specifies a choice item selected by the user > from the choice challenge. > > .../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected/@RefId > > A required attribute that specifies the reference identifier for the > choice item in the original choice challenge which can be used for > correlation. > > .../wst14:InteractiveChallengeResponse/wst14:ContextData > > An optional element that carries a context data item from the original > challenge that is simply reflected back. > > .../wst14:InteractiveChallengeResponse/wst14:ContextData/@RefId > > A required attribute that specifies the reference identifier for the > context data element in the original challenge which can be used for > correlation. > > .../wst14:InteractiveChallengeResponse/{any} > > This is an extensibility mechanism to allow additional elements to be > specified. > > .../wst14:InteractiveChallengeResponse/@{any} > > This is an extensibility mechanism to allow additional attributes to > be specified. > > In order to prevent certain types of attacks, such as > man-in-the-middle or replay of response, the challenge SHOULD be bound > to the response. For example, an STS may use the <ContextData> element > in the challenge to include a digest of any relevant replay protection > data and verify that the same data is reflected back by the requestor. > > > 8.3.2 PIN and OTP Challenges > > Two commonly used challenges, usually as forms of second > authentication factors, that require user interaction are: > > * a challenge for a secret PIN, > * a challenge for a one-time-password (OTP). > > This challenge may be issued by an STS using the “text challenge” > format within a user interaction challenge specified in the section > above. A requestor responds to the challenge with the PIN/OTP value > along with the corresponding /@RefId/ attribute value for the text > challenge which is used by the STS to correlate the response to the > original challenge. This pattern of exchange requires that the > requestor must receive the challenge first and thus learn the /@RefId/ > attribute value to include in the response. > > There are cases where a requestor may know /a priori/ that the STS > challenges for a single PIN/OTP and, as an optimization, provide the > response to the anticipated challenge in the initial request. The > following distinguished URIs are defined for use as the value of the > /@RefId/ attribute of a <TextChallengeResponse> element to represent > PIN and OTP responses using the optimization pattern. > > http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN > > http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/OTP > > An STS may choose not to support the optimization pattern above for > PIN/OTP response. In some cases, an OTP challenge from the STS may > include a dynamic random value that the requestor must feed into the > OTP generating module before an OTP response is computed. In such > cases, the optimized response pattern may not be usable. > > > 8.8 Challenge Examples > > > 8.8.1 Text and choice challenge > > Here is an example of a user interaction challenge using both text and > choice challenges. In this example, a user requests a custom token > using a username/password for authentication. The STS uses the > challenge mechanism to challenge the user for additional information > in the form of a secret question (/i.e./, Mother’s maiden name) and an > age group choice. The challenge additionally includes one contextual > data item that needs to be reflected back in the response. The user > interactively provides the requested data and, once validated, the STS > issues the requested token. All messages are sent over a protected > transport using SSLv3. > > The requestor sends the initial request that includes the > username/password for authentication as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > <wsse:Security> > > <wsse:UsernameToken> > > <wsse:Username>Zoe</wsse:Username> > > <wsse:Password Type="http://...#PasswordText">ILoveDogs</wsse:Password> > > </wsse:UsernameToken> > > </wsse:Security> > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityToken> > > <wst:TokenType>http://example.org/customToken</wst:TokenType > <http://example.org/customToken%3c/wst:TokenType>> > > <wst:RequestType>...</wst:RequestType> > > </wst:RequestSecurityToken> > > </S11:Body> > > </S11:Envelope> > > The STS issues a challenge for additional information using the user > interaction challenge mechanism as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityTokenResponse> > > <wst14:InteractiveChallenge xmlns:wst14="..." > > > <wst14:Title> > > Please answer the following additional questions to login. > > </wst14:Title> > > <wst14:TextChallenge RefId=http://.../ref#text1 > > Label="Mother’s Maiden Name" MaxLen=80 /> > > <wst14:ChoiceChallenge RefId="http://.../ref#choiceGroupA" > > Label="Your Age Group:" ExactlyOne="true"> > > <wst14:Choice RefId="http://.../ref#choice1" Label="18-30" /> > > <wst14:Choice RefId="http://.../ref#choice2" Label="31-40" /> > > <wst14:Choice RefId="http://.../ref#choice3" Label="41-50" /> > > <wst14:Choice RefId="http://.../ref#choice4" Label="50+" /> > > </wst14:ChoiceChallenge> > > <wst14:ContextData RefId="http://.../ref#cookie1"> .../ > /</wst14:ContextData> > > </wst14:InteractiveChallenge> > > </wst:RequestSecurityTokenResponse> > > </S11:Body> > > </S11:Envelope> > > The requestor receives the challenge, provides the necessary user > experience for soliciting the required inputs, and sends a response to > the challenge back to the STS as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityTokenResponse> > > <wst14:InteractiveChallengeResponse xmlns:wst14="..." > > > <wst14:TextChallengeResponse RefId="http://.../ref#text1"> > > Goldstein > > </wst14:TextChallengeResponse> > > <wst14:ChoiceChallengeResponse RefId="http://.../ref#choiceGroupA"> > > <wst14:ChoiceSelected RefId="http://.../ref#choice3" /> > > </wst14:ChoiceChallengeResponse> > > <wst14:ContextData RefId="http://.../ref#cookie1"> .../ > /</wst14:ContextData> > > </wst14:InteractiveChallengeResponse> > > </wst:RequestSecurityTokenResponse> > > </S11:Body> > > </S11:Envelope> > > The STS validates the response containing the inputs from the user, > and issues the requested token as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityTokenResponseCollection> > <wst:RequestSecurityTokenResponse> > > <wst:RequestedSecurityToken> > > <xyz:CustomToken xmlns:xyz="..."> > > ... > > </xyz:CustomToken> > > </wst:RequestedSecurityToken> > > <wst:RequestedProofToken> > > ... > > </wst:RequestedProofToken> > > </wst:RequestSecurityTokenResponse> > > </wst:RequestSecurityTokenResponseCollection> > > </S11:Body> > > </S11:Envelope> > > > 8.8.2 PIN challenge > > Here is an example of a user interaction challenge using a text > challenge for a secret PIN. In this example, a user requests a custom > token using a username/password for authentication. The STS uses the > text challenge mechanism for an additional PIN. The user interactively > provides the PIN and, once validated, the STS issues the requested > token. All messages are sent over a protected transport using SSLv3. > > The requestor sends the initial request that includes the > username/password for authentication as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > <wsse:Security> > > <wsse:UsernameToken> > > <wsse:Username>Zoe</wsse:Username> > > <wsse:Password Type="http://...#PasswordText">ILoveDogs</wsse:Password> > > </wsse:UsernameToken> > > </wsse:Security> > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityToken> > > <wst:TokenType>http://example.org/customToken</wst:TokenType > <http://example.org/customToken%3c/wst:TokenType>> > > <wst:RequestType>...</wst:RequestType> > > </wst:RequestSecurityToken> > > </S11:Body> > > </S11:Envelope> > > The STS issues a challenge for a secret PIN using the text challenge > mechanism as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityTokenResponse> > > <wst14:InteractiveChallenge xmlns:wst14="..." > > > <wst14:TextChallenge > > RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN" > > Label="Please enter your PIN" /> > > </wst14:TextChallenge> > > </wst14:InteractiveChallenge> > > </wst:RequestSecurityTokenResponse> > > </S11:Body> > > </S11:Envelope> > > The requestor receives the challenge, provides the necessary user > experience for soliciting the PIN, and sends a response to the > challenge back to the STS as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityTokenResponse> > > <wst14:InteractiveChallengeResponse xmlns:wst14="..." > > > <wst14:TextChallengeResponse > > RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN"> > > 9988 > > </wst14:TextChallengeResponse> > > </wst14:InteractiveChallengeResponse> > > </wst:RequestSecurityTokenResponse> > > </S11:Body> > > </S11:Envelope> > > The STS validates the PIN response, and issues the requested token as > follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityTokenResponseCollection> > > <wst:RequestSecurityTokenResponse> > > <wst:RequestedSecurityToken> > > <xyz:CustomToken xmlns:xyz="..."> > > ... > > </xyz:CustomToken> > > </wst:RequestedSecurityToken> > > <wst:RequestedProofToken> > > ... > > </wst:RequestedProofToken> > > </wst:RequestSecurityTokenResponse> > > </wst:RequestSecurityTokenResponseCollection> > > </S11:Body> > > </S11:Envelope> > > > 8.8.3 PIN challenge with optimized response > > The following example illustrates using the optimized PIN response > pattern for the same exact challenge as in the previous section. This > reduces the number of message exchanges to two instead of four. All > messages are sent over a protected transport using SSLv3. > > The requestor sends the initial request that includes the > username/password for authentication as well as the response to the > anticipated PIN challenge as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > <wsse:Security> > > <wsse:UsernameToken> > > <wsse:Username>Zoe</wsse:Username> > > <wsse:Password Type="http://...#PasswordText">ILoveDogs</wsse:Password> > > </wsse:UsernameToken> > > </wsse:Security> > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityToken> > > <wst:TokenType>http://example.org/customToken</wst:TokenType > <http://example.org/customToken%3c/wst:TokenType>> > > <wst:RequestType>...</wst:RequestType> > > <wst14:InteractiveChallengeResponse xmlns:wst14="..." > > > <wst14:TextChallengeResponse > > RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN"> > > 9988 > > </wst14:TextChallengeResponse> > > </wst14:InteractiveChallengeResponse> > > </wst:RequestSecurityToken> > > </S11:Body> > > </S11:Envelope> > > The STS validates the authentication credential as well as the > optimized PIN response, and issues the requested token as follows. > > <S11:Envelope ...> > > <S11:Header> > > ... > > </S11:Header> > > <S11:Body> > > <wst:RequestSecurityTokenResponseCollection> > > <wst:RequestSecurityTokenResponse> > > <wst:RequestedSecurityToken> > > <xyz:CustomToken xmlns:xyz="..."> > > ... > > </xyz:CustomToken> > > </wst:RequestedSecurityToken> > > <wst:RequestedProofToken> > > ... > > </wst:RequestedProofToken> > > </wst:RequestSecurityTokenResponse> > > </wst:RequestSecurityTokenResponseCollection> > > </S11:Body> > > </S11:Envelope> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]