Re: [KAML] Chicago bar-BOF summary

Leif Johansson <leifj@it.su.se> Mon, 27 August 2007 08:39 UTC

Return-path: <kaml-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPa8C-0006xJ-4a; Mon, 27 Aug 2007 04:39:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPa8A-0006x8-Ix for kaml@ietf.org; Mon, 27 Aug 2007 04:39:30 -0400
Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPa88-0003KI-Ol for kaml@ietf.org; Mon, 27 Aug 2007 04:39:30 -0400
Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 9F3B53BF6D; Mon, 27 Aug 2007 10:39:23 +0200 (CEST)
Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23927-01-20; Mon, 27 Aug 2007 10:39:23 +0200 (CEST)
Received: from [130.237.95.183] (dhcp-183.it.su.se [130.237.95.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 338A53BF04; Mon, 27 Aug 2007 10:39:23 +0200 (CEST)
Message-ID: <46D28DD1.5060809@it.su.se>
Date: Mon, 27 Aug 2007 10:39:45 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
MIME-Version: 1.0
To: Josh Howlett <Josh.Howlett@ja.net>
Subject: Re: [KAML] Chicago bar-BOF summary
References: <6ED388AA006C454BA35B0098396B9BFB028F5423@uxsrvr20.atlas.ukerna.ac.uk>
In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB028F5423@uxsrvr20.atlas.ukerna.ac.uk>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.901 tagged_above=-99 required=7 tests=[AWL=0.411, BAYES_00=-2.312]
X-Spam-Level:
X-Spam-Score: -4.0 (----)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: kaml@ietf.org
X-BeenThere: kaml@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <kaml.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kaml>
List-Post: <mailto:kaml@ietf.org>
List-Help: <mailto:kaml-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=subscribe>
Errors-To: kaml-bounces@ietf.org

Josh Howlett wrote:
>> The use-cases:
>>
>> 1. Was a smart-card used?
>>     
>
> Just to clarify; is this use-case describing 1) "LoA" for Kerberos or 2)
> extending SAML LoA to permit richer expressions?
>   
If you're asking about expressing LoA as attributes or in the
SAML authentication context I guess it depends on who is
consuming the LoA.
>  
>   
>> 2. The standarized PAC
>>
>> An AD domain controller includes data about the groups a user 
>> is a member of in the PA-DATA field of the KDC-REP. A 
>> generalization of this concept might be to include a SAML 
>> authentication response in the PA-DATA.
>>     
>
> ...presumably this could be further generalised to allow assertions in
> general, or even lower-level constructs such as an artifact (pointing to
> an assertion)?
>   
That would be my hope too.
>   
>> Hope this is enough to get things started. I know the
>> smart-card use- case was discussed on the heimdal 
>> list (although possibly not in the generality I 
>> presented above). Other use-cases have been discussed
>> on other lists.
>>     
>
> I'm curious whether we can use SAML, and the trust fabrics that are
> realised through SAML federation metadata, to support some kind of
> cross-realm Kerberos operation - perhaps using a SAML-based profile for
> inter-KDC communication (following PKCROSS' example)?
>
> The use-case would be a visitor requiring access to some local
> Kerberos-protected network resource, but no local credentials.
>   
Did you read draft-sakane-krb-cross-problem-statement? It looks
like you may be describing something related to 5.6 (in version 03)
> However, such a profile might also provide a way to avoid using the Web
> SSO Profile (in a browser context, obviously) and therefore side-step
> the associated IdP "discovery problem". The browser could authenticate
> using Negotiate (anonymously/pseudonymously) to the SP; authorisation
> could subsequently be performed using the familiar SAML-based
> mechanisms; perhaps boot-strapped through an artifact returned in the
> PAC (which is used as the discovery 'cue').
>
> best regards, josh.
>   
I guess its not so much side-stepping IdP discovery as it is using
the IdP discovery which has already happened. When the user
logs into the workstation she typically has to pick a realm to
authenticate to which is a form of IdP discovery - the metadata
beeing the DNS SRV records pointing to the KDC.

    Cheers Leif


_______________________________________________
KAML mailing list
KAML@ietf.org
https://www1.ietf.org/mailman/listinfo/kaml