Re: [plasma] Binary value encoding in AuthenticationTypeWSToken

"Jim Schaad" <jimsch@nwlink.com> Fri, 29 June 2012 02:52 UTC

Return-Path: <jimsch@nwlink.com>
X-Original-To: plasma@ietfa.amsl.com
Delivered-To: plasma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF22C11E8116 for <plasma@ietfa.amsl.com>; Thu, 28 Jun 2012 19:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PsXBWH1GoTJ for <plasma@ietfa.amsl.com>; Thu, 28 Jun 2012 19:52:28 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4029011E8085 for <plasma@ietf.org>; Thu, 28 Jun 2012 19:52:28 -0700 (PDT)
Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 46AB52C9B7; Thu, 28 Jun 2012 19:52:27 -0700 (PDT)
From: Jim Schaad <jimsch@nwlink.com>
To: 'Dan Griffin' <dan@jwsecure.com>, plasma@ietf.org
References: <B66E1F139A0F29418103E63A6124AC1C09FDFC0B@BY2PRD0511MB427.namprd05.prod.outlook.com> <018501cd54d9$3dae6c50$b90b44f0$@nwlink.com> <B66E1F139A0F29418103E63A6124AC1C09FE08F6@BY2PRD0511MB427.namprd05.prod.outlook.com>
In-Reply-To: <B66E1F139A0F29418103E63A6124AC1C09FE08F6@BY2PRD0511MB427.namprd05.prod.outlook.com>
Date: Thu, 28 Jun 2012 19:51:06 -0700
Message-ID: <020b01cd55a2$089e56f0$19db04d0$@nwlink.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_020C_01CD5567.5C4BDB00"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHyMd5/I3NLBHFDvMpYXySK4MLPhwGo45WOAdJ+TTqWqwK6oA==
Content-Language: en-us
Subject: Re: [plasma] Binary value encoding in AuthenticationTypeWSToken
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 02:52:30 -0000

Ok, the following response will not make you happy.  I suggest that you talk
to your employer about this issue.

 

1.        What kind of credential to get - That depends on what types of
credentials are used by your authentication framework.  The types of
credentials supported include SAML, X.509 certificates, GSS-API and WS-Trust
tokens.   There is no way for use to specify as single authentication method
as different companies use different methods.  Also we want to support some
very loose methods in non-company situations.

2.       Where/how to get it - That depends on what types of credentials are
used by your authentication framework.  You talk to plasma after you have
gotten credentials of some type, plasma does not tell you what type of
credentials you need, although it will tell you what attributes are needed
in the credentials (as part of the XACML response portion).

3.       What Plasma AuthenticationType type to map it to.  That depends on
what types of credentials are used by your authentication framework.  SAML
2.0 Assertions go into the SAML element (section 5.1.1), GSSAPI goes into
the GSSAPI element (section 5.1.4), X.509 certificates use the XML Digital
signature element (as might SAML if there is a holder of key statement)
(section 5.1.3).  Other types would go into locally defined Other (an
example would be SAML 1.0 Assertions) (external document - referenced from
section 5.1).

4.       How to do the encoding for that mapping.  That depends on what
types of credentials are used by your authentication framework.  See the
response to question 3.

 

 

Jim

 

 

 

From: Dan Griffin [mailto:dan@jwsecure.com] 
Sent: Thursday, June 28, 2012 4:16 PM
To: Jim Schaad; plasma@ietf.org
Subject: RE: [plasma] Binary value encoding in AuthenticationTypeWSToken

 

I'm referring to how the client authenticates to Plasma in the first place,
i.e. part of the work the client has to do before a single Plasma call is
made. The client will have to know:

 

1.       What kind of credential to get

2.       Where/how to get it

3.       What Plasma AuthenticationType type to map it to

4.       How to do the encoding for that mapping

 

The draft text doesn't appear to address #3 at all. How can you expect
interoperability? My first question remains unanswered. 

 

From: Jim Schaad [mailto:jimsch@nwlink.com] 
Sent: Wednesday, June 27, 2012 7:54 PM
To: Dan Griffin; plasma@ietf.org
Subject: RE: [plasma] Binary value encoding in AuthenticationTypeWSToken

 

Please let me know what text is unclear in the document.

 

This is A correct type  There is no ONE correct type of token to be
returned.  This is strictly a choice of the server.  The server can use an
XML based token, such as SAML or an ASN.1 based token, such as CMS or a
non-structured token, such as an index in a database.

 

There is no requirement in the document that the client understand the token
returned to the client.  In fact the requirement is just the opposite.  The
token is to be treated as an opaque blob by the client.  If data such as
lifetimes is to be returned they are returned as wst namespace attributes.

 

Jim

 

 

From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of
Dan Griffin
Sent: Wednesday, June 27, 2012 1:42 PM
To: plasma@ietf.org
Subject: [plasma] Binary value encoding in AuthenticationTypeWSToken

 

We're using AuthenticationTypeWSToken to transmit a SAML token - is that the
correct type?

 

If so, just wanted to clarify - the Value member of that type is a hex
binary string, which seems like an odd choice. Wouldn't XML make more sense?