RE: [KAML] LoA proposal

	Henry,

	My comments are inline.

	Regards,
	PR

-----Original Message-----
From: Henry B. Hotz [mailto:hotz@jpl.nasa.gov] 
Sent: Wednesday, September 19, 2007 3:04 PM
To: Paul Rabinovich
Cc: kaml@ietf.org
Subject: Re: [KAML] LoA proposal

Not sure there isn't a bit of scope creep in the proposal.  Seems to  
me the scope is providing authorization information based on how the  
original authentication was done, not to define new authentication  
mechanisms per-se.  We need to be careful what we say about OTP and  
SAML authentication in the absence of approved RFC's or other standards.

[PR] I do not propose to introduce support for new authentication
mechanisms. The document tries to document existing mechanisms used by Kerb
and, perhaps, those probable to be used in the medium term. To my knowledge
MS already issues Kerb tickets based on WS-Federation assertions with SAML
tokens consumed by MS ADFS.

I think we can "agree to disagree" on what what kind of authorization  
information is needed/appropriate based on prior discussion.  Let me  
suggest a different organization;  we should define two kinds of  
information:

1) RAW information, which provides details about how the original  
authentication was done.

2) EVALUATED information, which provides a policy judgement about the  
quality/strength/implications of the authentication method.

[PR] Perhaps, it's not clear from the document but the idea is for the
ticket to have one or more auth info's, one per profile. So, a TGT/ST may
have two profiles, one NIST (EVALUATED), one Simple (RAW) (or any number, as
we defined more profiles). It seems to me this makes it safer from future
evolution perspective as more profiles can be added (i.e., there may be many
EVALUATED profiles). KDC will have to be configured with a required set of
profiles (i.e., all STs in the realm will contain the same set).

Examples of RAW information would be the kind of OTP token used, or  
the cert (and/or cert path) for a PKINIT authentication.  If a SAML  
token caused the ticket to be issued then that SAML token might be  
included.

Examples of EVALUATED information would be a SAML token asserting the  
SP800-63 LoA of the authentication, or the PAC data defined by  
Microsoft.  DCE authorization info probably also qualifies (just to  
keep an ASN1-encoded type in the mix).

All of the above are optional, based on local policy requirements.   
Any/all of the above examples MUST be includable without conflict.   
Not that it would have been a problem, but the above clearly  
distinguishes whether a SAML token generated the authentication, or  
the authentication generated the SAML token, and both SAML tokens  
might be included.

I'd propose that the EVALUATED information gets included/excluded  
based on the same mechanism used by Microsoft to include/exclude the  
PAC.  I'd propose the RAW data is excluded by default, but included  
if requested by some other mechanism.

On Sep 19, 2007, at 7:55 AM, Paul Rabinovich wrote:

>
> 	Hello,
>
> 	In the attached document I attempted to summarize LoA-related  
> traffic in this and krb lists and to sketch a proposal. From Sam's  
> e-mail it looks like we need to produce an I-D by Oct 1. I'll start  
> right away on putting the proposal in the attached document into  
> the I-D format, and will send it out in the next couple of days.

----

> 11. The "simple" profile will support forwarding of authentication  
> info defined as a CHOICE:
>
> -       User ID/password: an ENUM or OCTET STRING saying "user ID/ 
> password".
> -       X.509 certification path: an ENUM or OCTET STRING saying "X. 
> 509 path" plus a SEQUENCE/SET of certificates.
> -       X.509 end-entity certificate only: an ENUM or OCTET STRING  
> saying "X.509 single cert" plus the certificate.I'd vote for an  
> ENUM on space efficiency grounds.

I'd vote for ENUM on space efficiency grounds.
> -       OTP: an ENUM or OCTET STRING saying "OTP" (QUESTION: are  
> there any important flavors/subdivisions?)
Take a look at section 5.1.1 of draft-ietf-krb-wg-kerberos-sam-03.txt.
> -       QUESTION: Is multifactor authentication of interest?
Absolutely.  If nothing else the use of multifactor authentication is  
needed for the higher levels in SP800-63, so it's already implied.   
Do we need to explicitly define a way to carry the number of factors  
used in the original authentication?  I don't think so, but I may be  
wrong.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu

RE: [KAML] LoA proposal

Attachment: smime.p7s