Subject: [abfab] draft-wei-abfab-fcla-02 is posted

From: [email-masked]
Date: Mon, 12 Mar 2012 17:18:59 +0800

Hi, all

  An updated version of Federated Cross-Layer Access 
(draft-wei-abfab-fcla-02) is posted.
  The major changes is in claust 4 :
 - 4. message flow
 - 4.1 fast re-authentication
 - 4.2 secure data sharing

here is the draft:
  http://www.ietf.org/id/draft-wei-abfab-fcla-02.txt

Any comments are appreciated!

-------------
Yinxing Wei

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 12 Mar 2012 13:16:50 +0100

Hi Yinxing:

I have seen that you have also mentioned and described the problem of fast re-authentication in your I-D. We have been just discussing as you may have noticed.

Although I am still in favor to define a general problem statement for this in ABFAB before going to solution space, I must say that here in UMU we have been thinking about a possible solution for providing this fast re-authentication procedure, which may have some similarities with yours.

Basically, since GSS-EAP is used in ABFAB to provide authentication, our idea is to use ERP (RFC 5296) (and the associated infrastructure) to provide fast re-authentication in ABFAB. After all, ERP is the standard to reduce the authentication time in EAP-based authentications.

In this way, we could extend GSS-EAP or create a GSS-ERP mechanism to transport ERP messages within GSS tokens. Something like:

 1. Initiator --> Acceptor:  GSS-EAP (EAP Initiate/Re-auth(SEQ, keyName-NAI,
                                cryptosuite,Auth-tag*)) 

   1a. Acceptor --> ER-Server: AAA-Request{Authenticator-Id,
                                EAP Initiate/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,Auth-tag*)

   2. ER-Server --> Acceptor: AAA-Response{rMSK,
                                EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,[CB-Info],Auth-tag*)

   2b. Acceptor --> Initiator: GSS-EAP (EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,[CB-Info],Auth-tag*))

Even the ER-Server could be placed near the server (local ER server) reducing the travel time of the messages. 

Obviously this is just an idea, which needs to be elaborated and discussed. In fact, as I said, I think it would be better to start defining a problem statement, requirements etc... for fast re-authentication in ABFAB. UMU would be willing to work on that.

Best regards.

El 12/03/2012, a las 10:18, [email-masked] escribió:

> 
> Hi, all 
> 
>   An updated version of Federated Cross-Layer Access (draft-wei-abfab-fcla-02) is posted. 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Luke Howard <[email-masked]>
Date: Mon, 12 Mar 2012 23:18:41 +1100

I haven't read the draft, but note that the Moonshot implementation provides fast reauth based on Kerberos tickets.

Sent from my iPhone

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 12 Mar 2012 13:44:04 +0100

Hi Luke:

That kind of fast re-auth based on Kerberos is also intrinsic to draft-perez-abfab-eap-gss-preauth-01

Best regards.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 09:40:41 -0400

>>>>> "Rafa" == Rafa Marin Lopez <[email-masked]> writes:

    Rafa> Hi Luke: That kind of fast re-auth based on Kerberos is also
    Rafa> intrinsic to draft-perez-abfab-eap-gss-preauth-01

    Rafa> Best regards.

    Rafa> El 12/03/2012, a las 13:18, Luke Howard escribi :

Right.  I'd prefer to focus on the Kerberos-based approaches because we
have a lot of experience with them (the Moonshot implementation and your
implementation) and because they seem to be rather simple.  I think for
the sorts of services that use ABFAB, ERP would require more
infrastructure and might be more complex.  Nothing precludes using
ERP--it's just another EAP method after all.  However for application
bridging it seems like there are environments where the two directions
we're already working on (gss-preauth and the reauth within Moonshot)
are far more attractive.

--Sam

---

From: [email-masked]
Date: Thu, 22 Mar 2012 10:58:47 +0800

Hi, Rafa:

  Thanks for your comments!
  Fast re-authentication is one promising mechanism to reduce the delay in 
access authentication.
  You have pointed out the possible ways for this scenario in abfab：
  - problem statment, requirement, solution(1. extend GSS-EAP, or 2. 
create a GSS-ERP mechanism)
 
  Your suggestion is fine for me.

------------
Yinxing Wei

Rafa Marin Lopez <[email-masked]> 
2012/03/12 20:16

收件人
[email-masked]
抄送
Rafa Marin Lopez <[email-masked]>, [email-masked]
主题
Re: [abfab]  draft-wei-abfab-fcla-02 is posted (fast re-auth)

Hi Yinxing:

I have seen that you have also mentioned and described the problem of fast 
re-authentication in your I-D. We have been just discussing as you may 
have noticed.

Although I am still in favor to define a general problem statement for 
this in ABFAB before going to solution space, I must say that here in UMU 
we have been thinking about a possible solution for providing this fast 
re-authentication procedure, which may have some similarities with yours.

Basically, since GSS-EAP is used in ABFAB to provide authentication, our 
idea is to use ERP (RFC 5296) (and the associated infrastructure) to 
provide fast re-authentication in ABFAB. After all, ERP is the standard to 
reduce the authentication time in EAP-based authentications.

In this way, we could extend GSS-EAP or create a GSS-ERP mechanism to 
transport ERP messages within GSS tokens. Something like:

 1. Initiator --> Acceptor:  GSS-EAP (EAP Initiate/Re-auth(SEQ, 
keyName-NAI,
                                cryptosuite,Auth-tag*)) 

   2b. Acceptor --> Initiator: GSS-EAP 
(EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,[CB-Info],Auth-tag*))

Even the ER-Server could be placed near the server (local ER server) 
reducing the travel time of the messages. 

Obviously this is just an idea, which needs to be elaborated and 
discussed. In fact, as I said, I think it would be better to start 
defining a problem statement, requirements etc... for fast 
re-authentication in ABFAB. UMU would be willing to work on that.

Best regards.

Hi, all 

here is the draft: 

------------- 
Yinxing Wei

abfab mailing list
[email-masked]

---

From: [email-masked]
Date: Thu, 22 Mar 2012 11:37:54 +0800

Hi, Sam:

     Comments for clarification.

     In RFC2743(GSS-API), there are some secentences:
       P4 "The security services available through GSS-API are 
implementable over a 
       range of underlying mechanisms based on secret-key and public-key 
cryptographic technoliges".

       P88 "Clause 5, Mechanism-specific example scenarios
       5.1 Kerberos V5 
       5.3 X.509 Authentication Framework"
 
     According to the text above, my understanding is that GSS-API can 
support
     a set of security mechanisms, it is NOT limited into the single 
Kerberos
     mechanisms. 

     In RFC5296(ERP), it says "3. ERP Description 
     ... ERP is a single round-trip exchange between the peer and the 
server; 
     it is independent of the lower layer and the EAP method used during 
     the full EAP exchange." 
     You wrote "ERP--it's just another EAP method after all". 

     I am not sure whether they are consistent. 

------------
Yinxing Wei

Sam Hartman <[email-masked]> 
发件人:  [email-masked]
2012/03/12 21:40

收件人
Rafa Marin Lopez <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [abfab] draft-wei-abfab-fcla-02 is posted (fast re-auth)

    Rafa> Best regards.

--Sam