Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 31

[Lee McGovern <[e-mail]>]

I agree with Bruno and Dick regarding version compliance

-----Original Message-----
From: OAuth <[e-mail]> On Behalf Of [e-mail]
Sent: Dienstag, 25. Februar 2020 01:56
To: [e-mail]
Subject: OAuth Digest, Vol 136, Issue 31

Send OAuth mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: OAuth Digest, Vol 136, Issue 30 (Bruno Brito)


----------------------------------------------------------------------

Message: 1
Date: Mon, 24 Feb 2020 21:55:35 -0300
From: Bruno Brito <[e-mail]>
To: [e-mail]
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 30
Message-ID:
	<CAKykFnKU-n1_LnoCkJikZAEww04GWq64A5=[e-mail]>
Content-Type: text/plain; charset="utf-8"

> a standard is more about documenting the current state of the art as
deployed in existing implementations.

For those whose still keep their ROPC grants working whats the problem about be OAuth 2.0 compliant?
And those who changes their implememntations, they will be OAuth 2.1 compliant, isn't simple?

Afterall the show must go on.

On Mon, Feb 24, 2020 at 9:14 PM <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific 
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: OAuth 2.1: dropping password grant (Aaron Parecki)
>
>
>
> ---------- Forwarded message ----------
> From: Aaron Parecki <[e-mail]>
> To: Brian Campbell <bcampbell=[e-mail]>
> Cc: Neil Madden <[e-mail]>, Matthew De Haast <matt= 
> [e-mail]>, "[e-mail]" <[e-mail]>, 
> "Richard Backman, Annabelle" <richanna=[e-mail]>
> Bcc:
> Date: Mon, 24 Feb 2020 16:13:42 -0800
> Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant I think we 
> might be going about this discussion the wrong way.
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell= 
> [e-mail]> wrote:
>
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
>> <[e-mail]>
>> wrote:
>>
>>> I?m not really sure the WG should be telling people what they ?ought 
>>> to be doing? unless we have concrete security or interoperability 
>>> reasons for doing so.
>>
>>
> I 100% agree that the job of a standard is not to tell people "what 
> they ought to be doing". Instead, a standard is more about documenting 
> the current state of the art as deployed in existing implementations.
>
> With that in mind, I think that leaves us with two concrete problems 
> with the password grant:
>
> 1) The actual problem with the password grant is end users entering 
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like 
> service accounts or backends that are inflexible, not actually using 
> it for end user credentials
>
> So it seems like there's actually something missing from OAuth which 
> is leading people to find the password grant and use that because it's 
> the only thing that most closely fits their existing model. It seems 
> like we'd be better off defining a new extension that captures the use 
> case people are actually doing, instead of encouraging the continuing 
> use of the password grant for this purpose.
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk <http://twitter.com/aaronpk>
>
>
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell= 
> [e-mail]> wrote:
>
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
>> <[e-mail]>
>> wrote:
>>
>>> I?m not really sure the WG should be telling people what they ?ought 
>>> to be doing? unless we have concrete security or interoperability 
>>> reasons for doing so.
>>>
>>> I also don?t agree that people doing this are doing anything wrong. 
>>> I don?t always agree with what our customers do, but I?ve learnt 
>>> over the years not to second-guess their reasons for doing it.
>>>
>>> Are Google wrong for using the JWT bearer grant (not client 
>>> credentials) and service accounts? They even go so far as to say 
>>> ?scopes are not a security mechanism? [1] and tell people to use 
>>> service account roles instead. (Precisely because they also support 
>>> non-OAuth auth methods, which bypass any scopes).
>>>
>>> Are we really going to tell them to rewrite it all to use the client 
>>> credentials grant?
>>>
>>> [1]:
>>> https://cloud.google.com/compute/docs/access/service-accounts#access
>>> copesiam
>>>
>>> > On 21 Feb 2020, at 21:04, Justin Richer <[e-mail]> wrote:
>>> >
>>> > +1. I?ve seen this anti-pattern deployed all over the place, and 
>>> > +it?s
>>> time to get rid of it and send people toward what they really ought 
>>> to be doing.
>>> >
>>> > Another thing I?ve seen is using different service accounts to get
>>> different sets of access for one client ? if you?re doing that, 
>>> you?ve got a client pretending to do two different things, or your 
>>> APIs should be using scopes to differentiate access instead of client/user identity.
>>> >
>>> > ? Justin
>>> >
>>> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 
>>> >> <richanna=
>>> [e-mail]> wrote:
>>> >>
>>> >> The client IDs can still be opaque identifiers provided by the 
>>> >> AS,
>>> they just happen to be associated with specific service accounts. Or 
>>> they could be the opaque IDs that the AS already issued for the service account.
>>> Either way, the AS could issue a token with the appropriate subject 
>>> and other claims for the service account.
>>> >>
>>> >> If your client identity is bound to a specific service account
>>> identity (i.e., the resource owner), then ROPC reduces down to 
>>> Client Credentials. What's the point in passing two identifiers and 
>>> two credentials for the same identity?
>>> >>
>>> >> ?
>>> >> Annabelle Backman (she/her)
>>> >> AWS Identity
>>> >> https://aws.amazon.com/identity/
>>> >>
>>> >>
>>> >> ?On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
>>> [e-mail] on behalf of [e-mail] 
>>> <neil.madden@forgerock...com>> wrote:
>>> >>
>>> >>   Sorry, I missed that message.
>>> >>
>>> >>   While this may be a solution in specific circumstances, I don?t
>>> think it?s a general solution. e.g. an AS may not allow manually 
>>> choosing the client_id to avoid things like
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#sect
>>> ion-4.13 or may return different introspection results for client 
>>> credentials tokens (e.g. with no ?sub?) and so on. In practice, this 
>>> adds even more steps for somebody to migrate from existing ROPC 
>>> usage.
>>> >>
>>> >>   This is asking people to make fundamental changes to their 
>>> >> identity
>>> architecture rather than simply switching to a new grant type...
>>> >>
>>> >>   ? Neil
>>> >>
>>> >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <
>>> [e-mail]> wrote:
>>> >>>
>>> >>> I see - we have gone full cycle :-)
>>> >>>
>>> >>> Annabelle?s proposal would solve that. Relate a client id to a
>>> service account and obtain the token data from there.
>>> >>>
>>> >>>> On 21. Feb 2020, at 15:31, Neil Madden 
>>> >>>> <[e-mail]>
>>> wrote:
>>> >>>>
>>> >>>> Yes, that is great. But mTLS doesn?t support service accounts 
>>> >>>> (!=
>>> clients). Maybe it should? Should there be a mTLS *grant type*?
>>> >>>>
>>> >>>> ? Neil
>>> >>>>
>>> >>>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <
>>> [e-mail]> wrote:
>>> >>>>>
>>> >>>>> Have you ever tried the client credentials grant with mTLS? 
>>> >>>>> After
>>> reading your description it seems to be simpler than JWT Bearer...
>>> >>>>>
>>> >>>>> * work out if the AS even supports mTLS
>>> >>>>> * work out how to configure the AS to trust my cert(s)
>>> >>>>> * Create key pair and cert using openssl
>>> >>>>> * Register your (self-signed) cert along with your client_id
>>> >>>>> * Configure the HTTP client to use your key pair for TLS 
>>> >>>>> Client
>>> Authentication
>>> >>>>>
>>> >>>>> Works very well for us.
>>> >>>>>
>>> >>>>>> On 21. Feb 2020, at 15:12, Neil Madden 
>>> >>>>>> <[e-mail]>
>>> wrote:
>>> >>>>>>
>>> >>>>>> No failures, but it is a much more complex grant type to set 
>>> >>>>>> up,
>>> when you consider everything you have to do:
>>> >>>>>>
>>> >>>>>> * work out if the AS even supports JWT bearer and how to turn 
>>> >>>>>> it
>>> on
>>> >>>>>> * work out how to configure the AS to trust my public key(s)
>>> >>>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>>> >>>>>> * determine the correct settings for issuer, audience, 
>>> >>>>>> subject,
>>> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 
>>> says that the JWT MUST contain a ?sub? claim, but Google only allows 
>>> this to be present if your client is doing impersonation of an 
>>> end-user (which requires additional permissions).
>>> >>>>>> * do I need a unique ?jti? claim? (OIDC servers do, plain 
>>> >>>>>> OAuth
>>> ones might not) If I do, can I reuse the JWT or must it be freshly 
>>> signed for every call?
>>> >>>>>> * locate and evaluate a JWT library for my language of choice.
>>> Monitor that new dependency for security advisories.
>>> >>>>>> * choose a suitable signature algorithm (?ere be dragons)
>>> >>>>>> * figure out how to distribute the private key to my service
>>> >>>>>>
>>> >>>>>> Compared to ?create a service account and POST the username 
>>> >>>>>> and
>>> password to the token endpoint? it adds a little friction. (It also 
>>> adds a lot of advantages, but it is undeniably more complex).
>>> >>>>>>
>>> >>>>>> ? Neil
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast <matt=
>>> [e-mail]> wrote:
>>> >>>>>>>
>>> >>>>>>> I have a feeling that if we had more concise JWT libraries 
>>> >>>>>>> and
>>> command line tools, where using the JWT Bearer grant became a 
>>> one-liner again then we wouldn?t be having this conversation. So 
>>> perhaps removing it is an incentive to make that happen.
>>> >>>>>>>
>>> >>>>>>> Neil could you elaborate more on this please. What failures 
>>> >>>>>>> are
>>> you currently experiencing/seeing with the JWT Bearer grant?
>>> >>>>>>>
>>> >>>>>>> Matt
>>> >>>>>>>
>>> >>>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <
>>> [e-mail]> wrote:
>>> >>>>>>> I have a feeling that if we had more concise JWT libraries 
>>> >>>>>>> and
>>> command line tools, where using the JWT Bearer grant became a 
>>> one-liner again then we wouldn?t be having this conversation. So 
>>> perhaps removing it is an incentive to make that happen.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <[e-mail]>
>>> wrote:
>>> >>>>>>>>
>>> >>>>>>>> Neil: are you advocating that password grant be preserved 
>>> >>>>>>>> in
>>> 2.1? Or do you think that service account developers know enough 
>>> about what they are doing to follow what is in 6749?
>>> >>>>>>>> ?
>>> >>>>>>>>
>>> >>>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <
>>> [e-mail]> wrote:
>>> >>>>>>>> OAuth2 clients are often private to the AS - they live in a
>>> database that only the AS can access, have attributes specific to 
>>> their use in OAuth2, and so on. Many existing systems have access 
>>> controls based on users, roles, permissions and so on and expect all 
>>> users accessing the system to exist in some user repository, e.g. 
>>> LDAP, where they can be looked up and appropriate permissions 
>>> determined. A service account can be created inside such a system as 
>>> if it was a regular user, managed through the normal account provisioning tools, assigned permissions, roles, etc.
>>> >>>>>>>>
>>> >>>>>>>> Another reason is that sometimes OAuth is just one
>>> authentication option out of many, and so permissions assigned to 
>>> service accounts are preferred over scopes because they are 
>>> consistently applied no matter how a request is authenticated. This 
>>> is often the case when OAuth has been retrofitted to an existing 
>>> system and they need to preserve compatibility with already deployed clients.
>>> >>>>>>>>
>>> >>>>>>>> See e.g. Google cloud platform (GCP):
>>> https://developers.google.com/identity/protocols/OAuth2ServiceAccoun
>>> t
>>> >>>>>>>> They use the JWT bearer grant type for service account
>>> authentication and assign permissions to those service accounts and 
>>> typically have very broad scopes. For service-to-service API calls 
>>> you typically get an access token with a single scope that is 
>>> effectively ?all of GCP? and everything is managed at the level of 
>>> permissions on the RO service account itself. They only break down 
>>> fine-grained scopes when you are dealing with user data and will be 
>>> getting an access token approved by a real user (through a normal auth code flow).
>>> >>>>>>>>
>>> >>>>>>>> ? Neil
>>> >>>>>>>>
>>> >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt <
>>> [e-mail]> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>> Can you explain more in detail why the client credentials
>>> grant type isn?t applicable for the kind of use cases you mentioned?
>>> >>>>>>>>>
>>> >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden <
>>> [e-mail]>:
>>> >>>>>>>>>>
>>> >>>>>>>>>> I very much agree with this with regards to real users.
>>> >>>>>>>>>>
>>> >>>>>>>>>> The one legitimate use-case for ROPC I?ve seen is for 
>>> >>>>>>>>>> service
>>> accounts - where you essentially want something like 
>>> client_credentials but for whatever reason you need the RO to be a 
>>> service user rather than an
>>> OAuth2 client (typically so that some lower layer of the system can 
>>> still perform its required permission checks).
>>> >>>>>>>>>>
>>> >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - 
>>> >>>>>>>>>> but
>>> they are a bit harder to implement. Having recently converted some 
>>> code from ROPC to JWT bearer for exactly this use-case, it went from 
>>> a couple of lines of code to two screens of code. For service to 
>>> service API calls within a datacenter I?m not convinced this 
>>> resulted in a material increase in security for the added complexity.
>>> >>>>>>>>>>
>>> >>>>>>>>>> ? Neil
>>> >>>>>>>>>>
>>> >>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt <
>>> [e-mail]> wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I would also seriously look at the original motivation
>>> behind ROPC: I know it has been deployed and is used in quite a lot 
>>> of places but I have never actually come across a use case where it 
>>> is used for migration purposes and the migration is actually 
>>> executed (I know that is statistically not a very strong argument 
>>> but I challenge others to come up with one...)
>>> >>>>>>>>>>> In reality it turned out just to be a one off that 
>>> >>>>>>>>>>> people
>>> used as an easy way out to stick to an anti-pattern and still claim 
>>> to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Hans.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <
>>> [e-mail]> wrote:
>>> >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively 
>>> >>>>>>>>>>> acting
>>> as a grace period since it currently says the password grant MUST 
>>> NOT be used, so in the OAuth 2.0 world that's already a pretty strong signal..
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Aaron
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <
>>> [e-mail]> wrote:
>>> >>>>>>>>>>> There is no need for a grace period. People using OAuth 
>>> >>>>>>>>>>> 2..0
>>> can still do OAuth 2.0. People using OAuth 2...1 will do OAuth 2.1.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> ? Justin
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <tonynad=
>>> [e-mail]> wrote:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are
>>> still sites using this and a grace period should be provided before 
>>> a MUST is pushed out as there are valid use cases out there still.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> From: OAuth <[e-mail]> On Behalf Of Dick
>>> Hardt
>>> >>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM
>>> >>>>>>>>>>>> To: [e-mail]
>>> >>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping 
>>> >>>>>>>>>>>> password
>>> grant
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Hey List
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder 
>>> >>>>>>>>>>>> for
>>> the doc that Aaron, Torsten, and I are working on)
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> In the security topics doc
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#sect
>>> ion-2.4
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> The password grant MUST not be used.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Some background for those interested. I added this 
>>> >>>>>>>>>>>> grant
>>> into OAuth 2.0 to allow applications that had been provided password 
>>> to migrate. Even with the caveats in OAuth 2.0, implementors decide 
>>> they want to prompt the user to enter their credentials, the 
>>> anti-pattern OAuth was created to eliminate.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Does anyone have concerns with dropping the password 
>>> >>>>>>>>>>>> grant
>>> from the OAuth 2.1 document so that developers don't use it?
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> /Dick
>>> >>>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>>> OAuth mailing list
>>> >>>>>>>>>>>> [e-mail]
>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>> OAuth mailing list
>>> >>>>>>>>>>> [e-mail]
>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>>>>>>> --
>>> >>>>>>>>>>> ----
>>> >>>>>>>>>>> Aaron Parecki
>>> >>>>>>>>>>> aaronparecki.com <http://aaronparecki...com> @aaronpk
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>> OAuth mailing list
>>> >>>>>>>>>>> [e-mail]
>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> --
>>> >>>>>>>>>>> [e-mail] ZmartZone IAM - 
>>> >>>>>>>>>>> www.zmartzone.eu 
>>> >>>>>>>>>>> _______________________________________________
>>> >>>>>>>>>>> OAuth mailing list
>>> >>>>>>>>>>> [e-mail]
>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>>>>>>
>>> >>>>>>>>>> _______________________________________________
>>> >>>>>>>>>> OAuth mailing list
>>> >>>>>>>>>> [e-mail]
>>> >>>>>>>>>> https://www.ietf...org/mailman/listinfo/oauth
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>> >>>>>>>>
>>> >>>>>>>> _______________________________________________
>>> >>>>>>>> OAuth mailing list
>>> >>>>>>>> [e-mail]
>>> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>>>
>>> >>>>>>> _______________________________________________
>>> >>>>>>> OAuth mailing list
>>> >>>>>>> [e-mail]
>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>>> _______________________________________________
>>> >>>>>>> OAuth mailing list
>>> >>>>>>> [e-mail]
>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> OAuth mailing list
>>> >>>>>> [e-mail]
>>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>
>>> >>   _______________________________________________
>>> >>   OAuth mailing list
>>> >>   [e-mail]
>>> >>   https://www.ietf.org/mailman/listinfo/oauth
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> OAuth mailing list
>>> >> [e-mail]
>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and 
>> privileged material for the sole use of the intended recipient(s). 
>> Any review, use, distribution or disclosure by others is strictly 
>> prohibited...  If you have received this communication in error, 
>> please notify the sender immediately by e-mail and delete the message 
>> and any file attachments from your computer. Thank you.* 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200224/cd451b71/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 136, Issue 31
**************************************


This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information.

Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender.
All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository.
If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.